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Preface 


Computers and humans have been struggling for almost thir- 
ty years to forge a new tool for visual creation. The ambitions 
of computer graphics practitioners have hurtled along with 
stunning improvements in imaging methods to the point to- 
day that realistic three-dimensional image synthesis is ready 
to take its place as a legitimate, rich medium for artistic expres- 
sion. The worldwide computer graphics research community 
has brought forth a host of powerful techniques all across the 
field, yielding a quality of realism that would have been too 
much to hope for twenty, or even ten, years ago. Increases in 
computer power have brought the machines to within the 
reach of ordinary mortals, and the quality of software for gen- 
erating images has improved in parallel. A field that began as 
a laboratory novelty and luxury is now ready to hand visual 
artists a mature technology for creating stunning three-dimen- 
sional images. 

The major remaining problem is familiar from other comput- 
ing technologies: tying it all together and making it accessible 
to people. The RenderMan Interface provides that access. It is 
a method for describing the content of an image to a comput- 
er program in the kind of detail required to reach realistic lev- 
els of complexity and quality. The two key characteristics of 
the interface are its conceptual simplicity and its complete- 
ness. RenderMan is about access to realism, and this book is 
about access to RenderMan. Cover to cover, every image in 
this book was rendered by a computer using the RenderMan 
Interface. 


The capabilities provided by RenderMan span much of 
present-day computer graphics. It is not practical to cover that 
topic from the ground up in one book. The ideal reader brings 
the equivalent of an undergraduate course in computer graph- 
ics. He or she should, however, be able to survive armed only 
with a feeling for three-dimensional geometry, an intuition 
into the nature of light reflection and enough experience with 
computers to read a program. Each discussion includes 
enough background to use the corresponding features, leav- 
ing out non-essential information. There are also suggested 
readings for anyone who wants more background. 

Those who will benefit most from the book are programmers 
who can generate computer models in enough detail to pro- 
duce interesting imagery. The RenderMan Interface is meant 
to be challenged, to expand the limits of what can be imagined 
with a computer. 


Structure of This Book 


This book .is divided into four parts. The first part is intended 
mainly to define terms and break ground for the remainder. 
Chapter 1 discusses the roots of synthetic imagery in the be- 
havior of light, and how RenderMan in particular reflects 
that process. A series of example programs in Chapter 2 step 
the reader through a basic RenderMan program, introducing 
specific aspects of the interface as they arise. After these exam- 
ples, the key concepts of the interface can be drawn in more 
detail in Chapter 3. 

After this introductory material. Parts II and IU should be self- 
sufficient. They separately address the topics of shape and 
shading. Part II covers shape, the description of geometric con- 
tent in three dimensions, as well as the process of viewing 
that content in an image. 

The ability to create interesting variations in shading is intro- 
duced in Part ID: lighting scenes as a whole, and controlling 
the reflective properties of objects in a scene. The fourth part 
describes the RenderMan facilities that are important for 
achieving the most powerful shading effects: the RenderMan 
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Shading Language. The shading language challenges the us- 
er's imagination by providing nearly complete control over 
the ultimate appearance of an image. 

The goal of this book is to help the reader make pictures. In 
the beginning, we set out the conceptual structures and terms 
embodied in the interface so that the actual routines and stan- 
dard methods make sense. That exposition begins with the 
broad discussions of the introductory chapters and culminates 
in the Glossary of Technical Terms found at the end. Every 
term is highlighted in boldface when first discussed or signifi- 
cantly expanded, and is summarized in the Glossary. 

To flesh out the conceptual material, there are program exam- 
ples at each point of discussion, beginning with the simplest. 
The examples should be useful for learning the interface and 
should serve as a model for writing other programs. 

Once the concepts are mastered and the examples assimilated, 
the book should serve as a useful reference to the functional- 
ity of the interface, so that the programmer can look back and 
quickly extract the information necessary for actually using a 
particular routine. Two features are provided for that pur- 
pose. When a given procedure is first discussed, its definition 
is set off in a box along with a terse description of the proce- 
dure's parameters and, if appropriate, a figure illustrating 
their meanings. At the end of the book. Appendix D declares 
all procedures in alphabetical order, together with the page 
where the boxed declaration appears. 

Appendixes A and C are also useful references; Appendix A 
summarizes the structure of RenderMan for determining 
what routines are appropriate at which point in a program, 
and Appendix C reproduces a C header file, ri.h, which de- 
clares all RenderMan types, routines and constants. Almost 
any RenderMan Tenderer will have a similar ri.h. 

Since this is a book about computer images, they are often 
used to illustrate points and concepts. All of the raster imag- 
ery found in the book was computer-generated, sometimes 
with line art added using Adobe Illustrator. All the synthetic 
imagery used the RenderMan Interface. 


Structure of This Book 
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Foreword 


The quest for realism in computer graphics has had an excit- 
ing history. We have seen an evolution from crude pictures 
made on expensive research machines to compelling images 
made on desktop computers. This quest has been one of the 
focal points of my professional life. It has been a fun and re- 
warding twenty years. 

Back in the early days of computer graphics we were happy to 
get any pictures at all. The objects had jagged edges and looked 
like they were made out of plastic, but we were full of ideas 
that could make them look better. Our goal was to make the 
images look real. 

Most of the early developments were at the University of 
Utah, where Dave Evans and Ivan Sutherland started a re- 
markable computer graphics program that attracted people 
from all over. In addition, Utah had a notable image process- 
ing group led by Tom Stockham. The first major task was to 
develop algorithms for determining what was visible in a 
scene, which led to the famous paper analyzing hidden-sur- 
face algorithms by Ivan Sutherland, Bob Sproull, and Bob 
Schumacher. My own contribution here was the develop- 
ment of the Z buffer. 

Better shading was the next major problem. Henri Gouraud 
discovered that he could substantially reduce the faceted ap- 
pearance of objects by linearly interpolating the values at the 
vertices of the polygons. Rui T. Phong took it a step further by 
interpolating the surface normals to get a smoother appear- 
ance as well as highlights. I made a contribution by develop- 
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mg texture mapping and the display of cubic patches. It was 
only at this point that I felt pictures were starting to look real- 
istic. Jim Blinn went on to extend texture mapping to include 
perturbation of surface normals, producing stunning pictures 
of oranges and strawberries. We had reached the point where 
the calculations required to shade became greater than those 
required to determine visibility. 

As computer graphics developed, major advances began to 
come from other places. I left Utah to become the director of 
the Computer Graphics Lab at the New York Institute of Tech- 
nology, where researchers from all over the country came to 
develop realistic images and animation. During the late 70's 
Cornell grew to be a major computer graphics institution un- 
der the direction of Don Greenberg. It was there that Rob 
Cook discovered that the lighting model everyone used best 
approximated plastic. He proposed a different model that let 
us simulate other surfaces such as metals. 

By the early 80's realism fever began to catch hold. Turner 
Whitted made ray tracing popular and thus started a caval- 
cade of advances in ray tracing. At first the pictures took ex- 
traordinarily long to produce — sometimes days. But again 
new algorithms were developed that made ray tracing more 
efficient. Around the same time SIGGRAPH became a phe- 
nomenon. Each year the proceedings had some great new pic- 
tures: fractals, plants, radiosity, cloth, and so on. Some criti- 
cized the emphasis on "pretty 7 pictures," but the excitement 
was undeniable. Every 7 time someone made a new discovery' 
it would be shown to colleagues, resulting in raves and ap- 
plause, and causing others to redouble their efforts to do even 
better. 



In 1979 Alvy Ray Smith and I had joined Lucasfilm to start 
the Computer Division, which later became Pixar. Some of 
the best people from the above institutions gathered to try to 
make images so realistic that they could be used in live-action 
motion pictures. 

We decided to throw the book out and start all over again in 
defining a system for creating extremely complex pictures 
with a high degree of realism. We had a phenomenal team — 
both Loren Carpenter and Rob Cook were amazingly produc- 
tive and creative. Rodney Stock suggested dithered sampling 
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and Tom Porter suggested spreading the samples over time. 
Rob generalized the shading formulas to "shade trees;" Pat 
Hanrahan and Jim Lawson generalized this to a shading lan- 
guage. 

The pictures were starting to look amazingly good. 

And just as important, we now understood what it meant to 
describe an image. This opened the door to the definition of an 
interface that could be independent of algorithms, hardware, 
and speed of execution. Pat Hanrahan put all that we knew 
about geometry, lighting models, ray tracing, antialiasing, mo- 
tion blur, and shade trees into a compact interface, which he 
named RenderMan. 

Our goal wasn't just to make photorealistic pictures; it was al- 
so to make the tools and systems that would let thousands of 
people create pictures of whatever they chose to design. Two 
more things were needed. Mickey Mantle, Tony Apodaca, Dar- 
wyn Peachey, and Jim Lawson took research code and made 
software that met the RenderMan specification. Finally, Steve 
Upstill took responsibility for explaining it all in this book. 

The quest for better pictures will continue, of course, but we 
have reached a new era. I am proud to be associated with the 
team that has made the results of twenty years of research 
available to everybody. 


Ed Catmull 
May 1989 


The RenderMan interface is meant to be the PostScript of 3-D 
graphics. Just as PostScript allows a desktop publishing system 
to pass page representations to a printer, RenderMan allows 
three-dimensional modeling systems to pass scene descrip- 
tions to a Tenderer. The design of the RenderMan interface 
has been the result of a great deal of experience designing and 
implementing rendering systems. 

In 1981 Loren Carpenter wrote the first rendering system at 
Lucasfilm. He named it REYES, which stood for Renders Every- 
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thing You Ever Saw. After its use for the Genesis effect of Star 
Trek II, the Wrath of Khan, Rob Cook and Ed Catxnull set out 
with Loren to redesign it to produce film resolution pictures 
of typical naturally occurring scenes. They estimated that a 
model of a natural scene would require 80,000,000 polygons, a 
level of complexity far beyond the capabilities or even aspira- 
tions of existing systems. This goal forced them to rethink ev- 
ery aspect of the rendering process. 

Another fundamental goal of the Lucasfilm group was to 
avoid digital artifacts in image production. The most trouble- 
some were those due to spatial aliasing (jaggies), but they 
came to realize that temporal aliasing was responsible for 
strobing artifacts during animation. A practical motion blur al- 
gorithm was therefore needed. A friendly competition among 
EcLLoren and Rob culminated in Rob's discovery of stochastic 
sampling, which led to practical solutions for spatial antialias- 
ing, motion blur, depth of field and a variety of other effects. 
One of the most challenging aspects of the RenderMan design 
was the goal to allow control over these effects, and image 
quality in general. 

During this period Rob also invented shade trees, which Jim 
Lawson and I have enhanced to be a complete shading lan- 
guage. The observation that modeling the optical properties 
of real materials requires the full generality of a programming 
language is perhaps the most important aspect of RenderMan, 
and one which distinguishes it from other graphics interfaces, 
which are usually based on a single large parameterized shad- 
ing model. 

It was painfully obvious that to routinely generate pictures 
containing 80,000,000 polygons in a reasonable amount of 
time would require special-purpose hardware. Tom Porter, 
Adam Levinthal, Mark Leather and Jeff Mock set out to de- 
sign a large-scale machine, named the REYES machine, to ren- 
der these types of pictures. The prospect of the REYES ma- 
chine led to the need for a standard interface between the 
scenes being produced by a modeling system and accepted by 
the rendering system. This interface is RenderMan. 

Bill Reeves and I designed the first version of RenderMan. 
Most notable was the fact that the interface was built around 
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curved-surface primitives. It was thought crucial that the 
modeling program not convert these into polygons, because 
this would lead to geometric artifacts (polygonal silhouettes) 
and shading artifacts (Mach bands) in the final images. In fact, 
rendering curved surfaces had always been an active area of 
research at Lucasfilm and Pixar, beginning with Tom Duff's 
quadric and Loren Carpenter's bicubic patch rendering algo- 
rithms. Of course, the process of choosing the exact set of 
primitives caused many heated arguments. In the end, we al- 
lowed for primitives that rendering systems could be expected 
to handle directly, without decomposition. 

Our initial specification was then circulated internally for an 
extensive design review. Tony Apodaca, Loren Carpenter, Ed 
Catmull, Rob Cook, Charlie Gunn, Paul Heckbert, Jim Law- 
son, Sam Leffler, Mickey Mantle, Eben Ostby,- Darwyn 
Peachey, Tom Porter, Bill Reeves, and Alvy Ray Smith all par- 
ticipated in these sessions at Pixar. During these discussions 
the style and content of the interface was largely decided. 

During this time we also began a joint project with Silicon 
Graphics to work on a three-dimensional graphics library us- 
able for both interactive graphics and high-quality rendering. 
Jim Clark contributed his thoughts on a simple graphics li- 
brary and Dan Baum, Paul Haeberli, Allen Leinwand, and 
Rob Myers at SGI contributed to the design. A major goal of 
this joint collaboration was to insure that the interface was 
compatible with emerging trends in real-time graphics work- 
station hardware. 

This version was then circulated to approximately 20 compa- 
nies for critical review. Included among these were compa- 
nies specializing in architectural and mechanical CAD, anima- 
tion production, and graphics workstations. Tom Porter and I 
personally met with graphics researchers at many of these 
companies and collected their thoughts and criticisms. Particu- 
larly helpful comments came from Andy Van Dam, David 
Laidlaw, and Jeff MacMann at Stellar; from Peter Schoeler and 
Gavin Miller at Alias; Kevin Hunter at Symbolics; Roy Hall at 
Wavefront; Doug Kay, George Joblove, and Lincoln Hu at In- 
dustrial Light & Magic; Michael Schantz, Lewis Knapp and Ei- 
leen McGinnis at Sun; and from Larry Gelberg and Tom 
Stephenson at TASC. 
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I was the chief architect and was responsible for incorporating 
the comments of the above individuals. During the final de- 
sign period Tony Apodaca was always available to discuss var- 
ious design alternatives. It was very difficult to pass a bad idea 
by him, but if I did, I alone am to blame. 

Pat Hanrahan 
May 1989 
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The Image-Rendering World 


r An astronomer recording images of distant galaxies 
* with an hours-long time exposure. A fashion photog- 
rapher snapping models in his amrtingly .lit studio. 
An Ansel Adams or Elliot Porter capturing the essence of nat- 
ural grandeur on film. A proud father trying to get his whole 
squirming family together in the view finder of his camera. 
These people are all creating images: putting a camera in front 
of some scene, providing or waiting for appropriate lighting, 
then focusing that light on film. 

Computers mimic that process to make synthetic images. The 
key parts of the process are defining, arranging and illuminat- 
ing a set of objects, and employing a viewing device to con- 
vert the three-dimensional scene into two dimensions. The 
difference is that all of these steps take place entirely inside a 
computer. 

This chapter discusses the parallels between the natural and 
the simulated worlds. The first section is a summary of how 
pictures come into being in the real world of physics and geo- 
metrical optics, and the second discusses how rendering pro- 
grams simulate that process. The third section draws a distinc- 
tion between modeling and rendering, and defines the role of 
the RenderMan Interface between them. Next there is a dis- 
cussion of the technology RenderMan is designed to harness. 
The final section describes how the computer process of im- 
age synthesis is driven by the interface. The idea is to assem- 
ble a global view of the RenderMan methodology and pro- 
vide a context for the rest of the book. 



Figure 1.1 Light interacting with objects and being seen by a viewer 


Making Pictures in the Real World 

Taking pictures in nature is a physical process that centers 
around light, its emission, transmission, reflection and refrac- 
tion. It ends when the light passes through the lens of an im- 
aging device such as a camera or an eye and finally falls on a 
recording surface. 

Figure 1.1 depicts the basic model of three-dimensional com- 
puter graphics. The process features three main elements. 
Light leaves a light source and travels in a straight line 
through space. It strikes, reflects from and (possibly) passes 
through objects, and ultimately arrives at a viewer, a term 
that includes both the eye and all varieties of camera. 

Secondary elements are the objects' surfaces, where light and 
object interact; and an atmosphere, which may alter the 
light's direction’ between objects or modify it as it moves to- 
ward the viewer. 

Emission 

Light pours out from light sources into the world in a straight 
path until it reaches the surface of an object 

Reflection and refraction 

When it reaches a surface, light is partially absorbed, partially 
reflected and, sometimes, partially transmitted. The surface 
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usually imparts a color different from the arriving light by ab- 
sorbing certain wavelengths more than others. Calculating 
the direction and color of the outgoing light is a complex prob- 
lem in geometrical optics, but it can be simplified by some fair- 
ly faithful approximations. 

Light may be reflected in different ways. Two simple cases rep- 
resent opposite extremes. A mirror reflection leaves the sur- 
face in one direction (called, appropriately enough, the mirror 
direction). Mirror reflections are only visible from view- 
points lying in the mirror direction; this specificity provides 
the coherence of objects seen in a mirror. A diffuse reflection, 
on the other hand, scatters light from the point struck, mak- 
ing the surface appear equally bright from all viewpoints. 
Most surfaces have neither completely mirror nor completely 
diffuse reflection but are graded somewhere in between. A re- 
flection concentrated near but not confined to the mirror di- 
rection is termed a specular reflection, or highlight. A specu- 
lar reflection is brightest when seen from viewpoints along or 
near the mirror direction, and becomes much dimmer away 
from that direction. 

If an object is partially transparent, then part of the light pass- 
es through it, perhaps with a slight refraction, or change of di- 
rection. 

Hiding 

If light leaves a point on a surface toward the viewer, it may 
strike another object before it gets there. If the second object is 
opaque, the point on the first object will be hidden from view 
and will not appear in the image. A surface is in shadow 
when it is hidden from a light source. 

Atmospheric effects 

Any light ray traveling between surfaces passes through the at- 
mosphere. Materials like dust and smoke suspended therein 
may introduce atmospheric effects that affect the resulting 
image. Common atmospheric effects include haze and fog, 
which make the light seem whiter, and pollution, which 
gives it a different, usually unpleasant, color. These kinds of 
atmospheric effects are important to realism partially because 
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they can provide depth cues, clues to the relative distances of 
objects. 

Projection 

After bouncing around in the world, some light winds up 
headed toward a viewer consisting of a viewing device, such 
as a camera or eye, which includes a viewing surface like film 
or a retina. The purpose of the viewing device is to organize, 
or project, the light as a coherent image onto the viewing sur- 
face. The image is simply a two-dimensional representation 
of a three-dimensional scene. 

Viewing devices have an optical system, either a set of lens- 
es or a pinhole, for assembling the image either by bending 
the light appropriately with a lens or by forcing it to pass 
through a pinhole. The process of arranging the image on the 
viewing surface usually has side effects on the content of the 
image, rendering some objects sharply and throwing others 
out of focus, bringing some objects nearer or showing them 
- from a wider field of view. 

Cameras and retinas 

Finally, light strikes the viewing surface. In the real world, 
the most common viewing surfaces are film, print media, 
photosensitive cathodes (TV tubes) and the retinas in the 
eyes of living organisms. The viewing surface may be flat or 
curved, and oriented at various angles with respect to the in- 
coming light, thus becoming part of the projection process. 
But every viewing surface has two key characteristics. First, it 
is two dimensional. This makes the viewing process one of 
projection, in the mathematical sense, from a three- to a two- 
dimensional world. Secondly, each viewing surface has gran- 
ularity: it is divided into physical sensors (grains of emulsion 
in film, halftone screen in print, photoreceptors in eyes, etc.), 
the density of which limits how much detail the visual sys- 
tem can extract from the image. 

Visual artifacts 

In addition to the processes above, certain artifacts can materi- 
ally affect the final image. If the image of a moving object is 
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exposed over time, it contains motion blur: the object appears 
"smeared." A lens used as a projection device has a character- 
istic known as depth of field: objects over a certain range of 
depth appear in sharp focus, while others outside that range 
appear blurred. The extent of that effect depends on the actual 
size of the opening (the aperture) that admits light, as well as 
on the focus of the camera. 

Completeness caveat 

This quick sketch minimizes or ignores a number of signifi- 
cant effects of real-world physics: relativistic effects such as 
bending due to gravity or the curvature of the universe, dif- 
fraction, fluorescence, variations in the speed of light, quan- 
tum effects, optical chromatic aberration, atmospheric scatter, 
holography, etc. These are ignored here (and in most of com- 
puter graphics) because they have comparatively little impact 
on images. 

Synthetic Rendering: How Computers Do It 

The real-world processes described above are reflected in the 
digital realm by the process of rendering. This section sketch- 
es the parallels between the two. 

Instead of objects, lights and cameras, the rendering process 
works on an internal representation of an imaginary scene 
in the world. The passage of light through the world, its inter- 
action with surfaces and its projection onto the viewing sur- 
face, are simulated by algorithms that operate on this internal 
representation. One principal job of the RenderMan Interface 
is to communicate scene descriptions to Tenderers, giving 
them enough information to form this internal representa- 
tion. 

Calculating light travel 

While there is no reason to dwell on the exact processes that 
simulate light in the world, there is one important difference 
between the real world and this computer model. Whereas in 
physics light pours out into the world, and only some of it ar- 
rives at a viewing surface, computers cannot afford to simu- 
late light that is never seen. An alternative model begins with 
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the viewing surface and traces rays back through the projec- 
tion process into the world. The former asks, "Light is head- 
ing out; where does it go?"; the latter "Where did the light hit- 
ting the viewing surface come from?" Fortunately, optical pro- 
cesses are mostly reversible, so the question can be answered. 
Virtually all rendering systems use this tactic. 

Hidden surface elimination 

The visibility of objects in a scene relative to a viewer is calcu- 
lated in the process of hidden-surface elimination. It is one of 
the most venerable topics in computer graphics, since it is 
both tricky to implement and computationally expensive. In 
fact. Tenderers are commonly distinguished primarily by the 
hidden-surface technique they use. 

Shading 

The shading portion of the rendering process calculates the 
appearance of an. object in a scene under a set of light sources. 
The shading process calculates the light leaving a surface as a 
function of the light striking the surface. Some of the factors 
most important to this process are the following: 

Colors of the surface and the light source(s). Their interac- 
tion is critical; a surface which appears blue under white light 
will normally appear black under a red one. The color of most 
real objects (a piece of wood, for example) changes from one 
point on its surface to another, giving it what is perhaps inap- 
propriately termed texture in computer graphics parlance. 
The meaning of "light source" should be flexible: a mirror or 
other particularly shiny object might use the whole world, its 
environment, as a "light source." 

Position and orientation of the surface relative to the light 
The greater the distance between a surface and a light source, 
or the more the surface faces away from the light, the darker 
the surface appears. In many cases, the orientation of a sur- 
face varies from point to point on the surface. The surface of 
an orange shows how much visual interest can arise solely 
from a variation in orientation. For some materials, the re- 
flected color even varies with orientation. 
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Roughness of the surface. The roughness of a surface refers 
to how light is scattered when reflected. A surface from which 
most outbound rays leave near the mirror direction will ap- 
pear shiny; one with a great deal of scatter will appear rough 
even though the individual variations are too small to be re- 
solved. A shiny material like metal appears very unmirror- 
like if its surface is roughened to a matte finish. 

Computing the outgoing color and direction of the light strik- 
ing a surface can be complicated and expensive, requiring clev- 
er simplifications and approximations to make it tractable. 
Both the physics of shading and the problem of finding ade- 
quate approximations to it have held considerable attention 
in computer graphics in recent years, with more progress still 
to be made. On the positive side, control over shading exerts 
the most powerful and subtle influence over the ultimate ap- 
pearance of an image. There is probably more room for cre- 
ativity and innovation in the shading process than in any oth- 
er aspect of rendering. 

A good rendering system helps users cope with the complexi- 
ty of shading in three ways: by predefining powerful proce- 
dures to hide its complexity behind a few intuitive parame- 
ters, by making it possible to write specialized extensions, and 
by making it easy to incorporate improvements developed by 
others. The later parts of this book will demonstrate how the 
RenderMan Interface satisfies all three. 

Atmospheric effects 

A few rendering systems modify light on the way from sur- 
face to viewer. These effects usually depend on the color of 
the light and the properties of the intervening atmosphere, in- 
cluding its color, moisture content and density. Their effects 
are usually more profound the greater the distance between 
viewer and object. 

Camera model 

The camera model typically used in computer graphics is a 
simple pinhole. Computationally, this is a very easy ap- 
proach, since one can calculate a color at a given point on the 
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Figure 'Ll Pinhole viewer 


viewing screen by projecting a line back from that point 
through the pinhole and out into the world (see Figure 1.2). 

A pinhole camera is a simple example of perspective projec- 
tion from world to screen, a term which indicates that objects 
near the viewpoint appear larger than farther objects of simi- 
lar size. It is also possible to use an orthographic projection, 
which is like an infinitely long telephoto lens: all objects ap- 
pear to be the same size regardless of their distance. 

These simple projections produce images in which every ob- 
ject is in perfect focus. A more complicated technique is to 
model a camera complete with a lens and non-infinitesimal 
aperture, or opening. Then, depending on the size of the aper- 
ture, and the focal length and focus of the lens, it becomes pos- 
sible to introduce depth of field artifacts: objects within a cer- 
tain range in depth appear in focus, and those outside that 
range appear blurred. Advanced Tenderers may also be capable 
of blurring the image of a moving object 

Viewing surface 

One constant among realistic computer-graphic camera mod- 
els is a rectangular viewing screen divided into thousands of 
picture elements, or pixels. Each pixel represents the color of 
the image at a point, typically (but not necessarily) as three 
smaller dots of red, green and blue. Taken together, the three 
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parts of a pixel can represent a wide variety of colors as inde- 
pendent variations of those three primaries. 

Since the pixels are arranged on a regular grid, the resolution 
of the viewing screen can be specified as the number of rows 
and columns of pixels that make up the screen. An image in 
the graphics sense is such a two-dimensional rectangular ar- 
ray, or raster, of pixels. There are two contrasting, but useful, 
ways to view the notion of a pixel. 

Pixels as screen dots 

One view is that the pixels of an image may be used to drive a 
display, a full-color monitor, to see the image of the scene. In 
this view, each pixel in the image represents the color of one 
dot on the screen. The resolution of the screen determines the 
power of the resulting image to resolve details of the world 
when viewed. 

Pixels as samples 

In the second view, that of the rendering process, a pixel repre- 
sents a sample in time and space, the color of a part of the 
world as projected onto the viewing surface during the expo- 
sure of the image. Since a pixel on a viewing surface is finite 
(though small) in size, it represents a view of all the surfaces 
within some slender pyramidal volume of space. An image 
retains no notion of the surfaces and geometry involved, and 
must content itself with a single color at each pixel. This is cal- 
culated by filtering the scene data projected near a pixel into a 
single color. 

In the real world, each viewing surface contains sensors 
(grains of film, rods and cones of the eye, etc.) at the pixel loca- 
tions: The filtering characteristics of the viewing surface then 
become a function of the sensor's response, the optical system 
projecting onto the sensor and the influence exerted by neigh- 
boring sensors. 

Importance of filtering 

Given the small size of a pixel, filtering sounds like a very 
straightforward process, but in fact there are many different 
ways to filter an image. The choice of filtering technique can 
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Figure 13 faggies: left, an unfiltered image; right, a filtered version 


have pronounced effects on the ultimate quality of the image. 
Bad or nonexistent filtering results in aliasing, the most com- 
mon example of which is j aggies: if each pixel represents the 
light hitting the screen from one precise, infinitesimal direc- 
tion, then each pixel will be colored entirely by exactly one 
point on one surface. If some object has a straight edge in- 
clined slightly with respect to the rows or columns of pixels, 
and it contrasts strongly with its background, the result is a 
staircase effect (see Figure 1.3), which is especially pronounced 
in images of thin lines. It is particularly annoying when ob- 
jects are animated, their edges crawling with jaggies. 

The optical systems of the real world do a fairly good job of 
eliminating aliasing by their nature. Computer models re- 
quire filtering to be added as a separate, potentially expensive, 
process. However, it is essential to truly high-quality realistic 
imagery. 

Quantization 

One final problem in the computerized sampling process con- 
cerns quantization, the process of reducing a sample pixel val- 
ue to one of a number of fixed values. While pixel values as 
computed may be arbitrarily precise, digital displays can dis- 
play pixels at only a small number of discrete levels. If the dy- 
namic range of a display is divided evenly among those lev- 
els, and the number of levels is too small, then abrupt chang- 
es (false contours) appear where the image intensity changes 
from one level to another. 
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Modeling vs. Rendering 

Making pictures involves two basic concerns. One is subject to 
creative control, and the other is not. The photographer, or 
the image synthesist, works to arrange a scene and organize it 
for a camera. He has great control over lighting, composition, 
and framing, all elements that vary from picture to picture. 
However, all pictures are created in the context of a physical 
universe, whether real or simulated, which is the same from 
picture to picture: light emission, reflection and transmission; 
the projection of light through lenses onto film; the photosen- 
sitivity of film, etc., do not vary. 

The first sections of this chapter described the latter elements 
in detail. Embodying those elements in a rendering program 
requires enormous amounts of computing power and pro- 
gramming sophistication for every spot in the image, inde- 
pendent of the actual image content. However, once that pro- 
gram is written — once the universe is formed — creating a 
synthetic image becomes a matter of setting up those ele- 
ments that make each image unique, of arranging objects and 
light sources, placing a camera, and so on. 

RenderMan exists at the boundary between the two. The pro- 
cess of setting up a scene goes by the name modeling; the 
scene is turned into an image via the physical simulation 
called rendering. One of the tenets of RenderMan is that it is 
important and useful to recognize the distinction between the 
two. 

Rendering is a very difficult problem, but it is relatively sta- 
ble. Since it is based on physical reality, a user's demands in 
the rendering domain are not likely to change. Modeling, on 
the other hand, is not so stable in terms of systems designed 
to support it. An architect's modeler, for example, looks very 
different from a mechanical-parts design system. As there is 
no end to the need for new modelers, it makes sense to sepa- 
rate the rendering part of making pictures and provide all 
modelers access to the same rendering solution. If the inter- 
face between these modelers and the Tenderer is sufficiently 
general, any modeler can use any Tenderer driven by that in- 
terface. 
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The overriding goal of the RenderMan Interface is to meet 
the needs of diverse modelers in accessing the power of a vari- 
ety of Tenderers. 

What is RenderMan? 

RenderMan is first of all a scene description methodology: a 
comprehensive way to describe objects, scenes, lights and cam- 
eras so that a computer can create images from them. A user 
of the RenderMan Interface writes, compiles and runs a pro- 
gram in a conventional programming language, calling a set 
of special procedures to describe a scene. Some procedures 
specify the color and placement of objects, while others con- 
trol the camera viewing the scene and the lights that illumi- 
nate the objects. 

But while RenderMan's scene description facilities are com- 
plete, its true power lies in its facilities for describing the ap- 
pearance of objects. The visual interest of much of the world 
comes not from shape, the geometric configuration of objects, 
but from shading. A typical room environment includes ob- 
jects of relatively simple shape (the most geometrically com- 
plex object in an office, for example, is often the telephone), 
but wildly varying surface qualities: the paint on the wall may 
vary from matte to glossy; the . underlying surface may be 
smooth, pebbly or anything in between; metal appears shiny 
or burnished; practically ever)' kind of plastic has its own idio- 
syncratic texture; finished wood varies across its surface not 
only in color but also in shihiness. Natural environments are 
even more diverse. The visual complexity, or detail, seen in 
these environments arises much more from these surface 
variations than from the surfaces' overall geometry. 

The second purpose of RenderMan is to bring this kind of sur- 
face variety to synthetic imagery. The key is flexibility in shad- 
ing the surfaces in the scene. Geometry is described using Ren- 
derMan procedures, and the expectation is that any reasonable 
scene can be configured using them. Appearance,, on the other 
hand, is governed by a special programming language for de- 
scribing how light sources emit, light, surfaces reflect and 
transmit it, and the atmosphere affects it Procedures written 
in this shading language are associated with individual sur- 
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faces and called during rendering so that the shading can vary 
with position on the surface, angle of view, time, etc. The 
power of this approach can be seen in the color plates later in 
the book: the geometry is identical for each of the light bulbs 
there; only the shading procedures vary. 

The closest that most current computer graphics systems 
come to this level of flexibility is the ability to apply images, 
or texture maps, to surfaces in the manner of a decal. A wood- 
grain texture can be obtained, for example, by using a photo- 
graph of wood as a texture map. The shading language, on the 
other hand, subsumes this approach: not only an image, but 
any function of position on the surface can be used to modu- 
late the surface's appearance. Even better, a texture map can be 
used as input to a shading language routine and so the shader 
can operate not just on position, but on any function of posi- 
tion. For example, an inlaid tabletop can be rendered by using 
a texture map to determine what material to apply where. 

The key idea behind RenderMan is the separation between 
the modeling and the rendering domains. The development 
of a modeling system no longer requires concurrent develop- 
ment of a Tenderer. A modeling system using the RenderMan 
Interface has immediate access to the full power of all features 
of RenderMan, including the shading language. The modeler 
can also choose a Tenderer on any basis that seems appropri- 
ate: cost, efficiency, speed or image quality. This selection of 
Tenderer may even change during the development of a sin- 
gle model. Designs often proceed from "roughing out" with 
crude object placement, to "fine-tuning" attributes of lighting 
and shading. 

There are a variety of reasons to use a well-defined standard 
interface between modeling and rendering: 

• It becomes feasible to compare a variety of solutions to the 
rendering problem, not only for efficiency but for capabili- 
ty. The set of capabilities defined in the interface provides 
a comprehensive checklist of features for software support- 
ing that interface. 

• It becomes possible to choose an appropriate Tenderer for 
different stages of the modeling process with different re- 
quirements for speed and quality. 
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• The nature of the output device need no longer be a con- 
cern of the modeler. 

• Renderers can continue to evolve and improve with a 
minimum of attention from modelers. 

• A flexible interface can be used in novel ways simply by 
loosening the definition of ''rendering/' For example, a 
three-dimensional scene could be represented as line 
drawings in a book by "rendering" scene data with Post- 
Script commands. 


What RenderMan Offers 

Later chapters address writing programs with the RenderMan 

Interface. The remainder of this one relates the facilities pro- 
vided by the interface to the synthetic rendering model dis- 
cussed earlier. 

Here is a summary of the features RenderMan includes: 

• A small, powerful set of primitive surface types. The 
types of geometric primitive included in the interface are 
basic: they do not readily reduce to simpler primitives 
without sacrificing either efficiency or information useful 
in rendering. 

• Hierarchical modeling. Surface primitives may be group- 
ed together and treated as a single composite object with 
common properties. 

• Constructive Solid Geometry. Objects may be defined by 
taking the union, intersection or difference of other ol> 
jects. 

• Hierarchical geometry. RenderMan supports a stacked geo- 
metric transformation environment. 

• Camera model. The RenderMan Interface provides a low- 
level camera model and the ability to specify an arbitrary 
geometric transformation in projecting a scene into an im- 
age. Real camera attributes like motion blur and depth of 
field can be specified. 

• Shading attributes. An advanced Tenderer should be able 
to get any information it needs to produce its pictures. 
Since any such information can be ignored by more primi- 
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tive Tenderers, RenderMan supports a wide variety of 
shading attributes. 

• Extensibility. User definitions and procedures can be in- 
cluded in the RenderMan Interface at many key points, in- 
cluding object definitions, geometric transformations, ap- 
pearance attributes and shading. 

• Generalized shading model. The method by which object 
and light positions and colors are transformed into image 
colors is generalized by RenderMan: shading models can 
be expressed by the user as a procedure in the RenderMan 
Shading Language. 

There are other potential features of a rendering interface that 
are left out of RenderMan, either because they compromise its 
conceptual simplicity, or because it is better to do one thing 
well than several things poorly. Accordingly, the RenderMan 
world leaves out the following: 

• Abstractions peculiar to modelers. In the interest of sim- 
plicity and generality, RenderMan avoids encroaching on 
the modeling realm. High-level objects can be reduced to 
RenderMan' s basic surface types. The same philosophy is 
applied to camera characteristics: a variety of useful param- 
eters is built into the system, sufficient for expressing 
more human-oriented controls. 

• Implementation details. As part of its role as a standard, 
the RenderMan Interface should not care about the nature 
of any Tenderer for which it serves as a front end. Any im- 
plementation-dependent information can be communicat- 
ed using one of the "back-door" methods included in the 
interface. 

• Editable display list. The models built up by the interface 
are write-once: it is not possible to modify a single object 
or transformation from one image to the next. Scenes 
must be specified in their entirety for each image. Howev- 
er, it is possible to define invariant parts of a model, then 
efficiently create instances of them at each frame. 

• Database capabilities. RenderMan is not a database sys- 
tem. Descriptions of models may only be passed into the 
interface. There is no mechanism for reading back the de- 
scriptions. Database issues are so important that to include 
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them in RenderMan would have complicated the render- 
ing interface and probably would not have produced a 
good database system either. 
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CHAPTER 2 


Getting Started 


r This chapter and the next are complementary parts of 
* a first discussion of RenderMan. This chapter is 
"bottom-up," starting with a simple example program 
and progressing to more elaborate ones, introducing concepts 
and principles as they arise. In the next chapter, a more "top- 
down" approach groups those concepts and principles accord- 
ing to function and provides more detail. Taken together, the 
two chapters should provide the groundwork for specifics laid 
out in later chapters. 

The programs' here introduce the basics of creating an image 
with the RenderMan Interface: creating and viewing a simple 
object, replicating it to make a more interesting object, color- 
ing objects using the graphics environment, and creating an 
animation by modifying a scene over time. The examples are 
deliberately simplified. The goal is not to create mind-bog- 
gling graphics, but to set out some key concepts in the context 
of specific code. The elaborations of later chapters introduce 
more interesting object, lighting, shading and viewing proce- 
dures. 

A Basic Program 

The first example program, shown in Listing 2.1, does every- 
thing necessary to produce an image: initialize the interface 
and create a scene by describing an object to be rendered. 

The most obvious characteristic of the program is that it is 
written in the C language, as are all the examples in this book. 
The RenderMan Interface is not limited to C. Its procedure 
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^include <ri.h> 

RtPoint Squared] = { {.5,.5,.5}, {.5, -.5,-5), M,-,5,.5), (-.5, .5, .5} 
); 

main() 

1 

RiBegin(RLNULL); /* Start the renderer */ 
RiWorldBeginO; 

Ri$urface( “constant*’, RLNULL); 

RiPolygon( A, /* Declare the square */ 
RI_P ; (RtPointer) Square, RLNULL); 
RiWorldEndO; 

RiEndQ; A Clean up V 

) 

Listing 2.1 A minimal program using RenderMan 


calls may be transported to other languages, even an interpret- 
ed command language. For the time being, though, C is the 
most convenient explanatory medium. 

Initializing the environment 

The first line of the program, the call to RiBeginO, initializes 
the RenderMan Interface. These initialization tasks are essen- 
tial: Any program using the RenderMan Interface must first call 
RiBeginO and eventually call RiEndQ. 

Describing the world 

The second line is a call to RiWorldBeginO, matched later with 
a call to RiWorldEndO. The former signals that the application 
is about to begin describing a specific scene by passing geomet- 
ric data across the interface. The latter indicates that the scene 
is complete. 

Appearance 

After RiWorldBeginO there is a call to RiSurfaceO. The charac- 
ter string "constant" passed as a parameter to RiSurfaceO indi- 
cates that surfaces in the scene will be rendered with a con- 
stant color. That fact explains how this scene can be seen with- 
out a light source. 
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Specifying an object 

Only one object appears, in this scene: a square declared by the 
call to RiPolygonO. The information necessary to define the 
square is contained in Square, an array of four RtPoints. Each 
RtPoint is a floating-point triple specifying a point in three-di- 
mensional space. When passed to RiPolygonO this way, each 
RtPoint represents a vertex, the x, y and 2 locations of a comer 
of the polygon. The vertices are connected by line segments in 
the order the triplets appear in Square ; those line segments de- 
fine the boundary of the polygon. 

The first argument to RiPolygonO gives the number of verti- 
ces in the polygon. The next two arguments constitute a to- 
ken-value pair the first is a character string, passed as an Rt- 
Token, and the second is an array passed as an RtPointer. The 
character string indicates the type of data in the array. Here, 
the predefined string RI_P denotes an array of points giving 
positions in three-dimensional space. The RiPolygonO routine 
interprets them as the polygon's vertices, and assumes that they 
are given in clockimse order. RiPolygonO allows for any number 
of token-value pairs, so that a variety of values may be at- 
tached to the vertices of a polygon. Other possibilities will be 
discussed in later chapters. 

Both RiSurfaceO and RiPolygonO have RI_NULJ. as the last ar- 
gument. It is used here as a terminating token, since there is 
no other way for the procedure being called to know exactly 
how many token-value pairs are being passed to it. 

Result 

The program in Listing 2.1 is austere, but complete as far as 
RenderMan is concerned. When compiled and run, it should 
create an image with a square in its middle. This might seem 
peculiar, considering that there is no mention of display any- 
where in the program. There are defaults for much of the be- 
havior controlled by RenderMan, and in this case the default 
is to produce an image file named ri.pic. 

Why does the square appear in the middle of the image? The 
default view is an orthographic projection aimed along the z 
axis so that the screen includes every point which is in posi- 
tive 2 with an x and y value within the range -1 to +1. The x 
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(y) values of -.5 and +.5 therefore describe points one-quarter 
and three-quarters of the way across (up) the screen. 

Controlling the Picture 

The next job is to view the square from a more interesting, or 
at least different, angle. The program in Listing 2.2 also shows 
how to give it a different color, provide a light source, and use 
a perspective projection. 


^include <ri.h> 


RtPoint Squared] = I i.5,.5,0), 1.5, -5,0], (-5, -5,0], i-5,.5,0} ]; 


static RtColor Color = { .2, A, .6 }; 

mainO 

1 

RiBegin(RLNULL); /* Start the renderer */ 

RrLightSource( "distant! ighf, RLNULL); 

RiProjection( "perspective' 1 , RLNULL); 
RiTranslatefO.O, 0.0, 1.0); 

RiRotate(40.0, -1.0, 1.0, 0.0); 

RiWorldBeginO; 

RiSurface( "matte", RLNULL); 

RiColor(Color); /* Declare the color */ 
RiPolygon( 4, /* Declare the square *f 

RLP, (RtPointer) Square, RLNULL); 

RiWorldEndO; 

RiEnd(); /* Clean up after the renderer */ 


Listing 2.2 Control over viewer and color 


Preparing a light source 

The first call after RiBeginO is to RiLightSourceQ, passing it the 
character string “distant! ighf*. A distant light source functions 
like the sun: its brightness does not vary with distance, and its 
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rays are essentially parallel. Although other configurations 
are possible (as we'll see in Chapter 11), the default distant 
light points along the positive z axis. 

Perspective projection 

Listing 2.2 then declares a perspective projection by calling 
RiProjectionO with the character string "perspective". Now the 
image will include any object with a positive z value, but only 
if the z value is greater than the absloute value of either x or 
y. In other words, the perspective image captures objects in- 
side a pyramid whose peak is at the origin opening along z. 

The effect of a perspective projection can be compared by run- 
ning the program both with and without the RiProjectionO 
call. When the perspective is applied, one comer of the square 
looms large, and the other is foreshortened with distance. In 
an orthographic projection the rotated square is symmetric. 

Changing the viewer 

After the light source and projection are declared, two routine 
calls in Listing 2.2 redefine the viewing parameters of the 
scene. The first, RiTransiate(0.0, 0.0, 1.0), is a geometric trans- 
formation specifying that all subsequent surfaces should be 
spatially transformed for viewing. The three parameters to Ri- 
TranslateO specify motion along the x, y and z axes, respective- 
ly. This call causes objects in the scene to be translated by 1.0 
along the z axis. Since the viewpoint is at the origin pointing 
along the positive z axis, the entire scene is moved away from 
the viewer. 

The RiRotate(40.0, -1 .0, 1 .0, 0.0) call is another geometric 
transformation causing any subsequent surfaces to be rotated 
about a line in space. The first parameter specifies the amount 
of rotation in degrees. The last three parameters give a point 
in 3-space; the axis of rotation passes through this point and 
the coordinate origin. In this case we have specified that the 
whole world will rotate by 40 degrees about a line in the z= 0 
plane pointing up (y=1.0) and to the left (x=-1.0). The rotation 
is left-handed: if a person's left thumb points along the axis of 
rotation from the origin to the given point, the other fingers 
curl to point in the direction of positive rotation (see Figure 
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Figure 2.1 Left-handed rotation about an axis 


2.1). As we will see in Chapter 7, the handedness of the coordi- 
nate system is subject to change by the application. 

The order in which these two routines are called is very impor- 
tant the transformation specified last is performed first. Listing 2.2 
calls for a rotation followed by a translation: the axis of rota- 
tion is much nearer the object being rotated than it would be 
if the translation were performed first. In the latter case, the 
object would be rotated right out of view. 

A different appearance 

Listing 2.2 has a different call to RiSurfaceO, this time passing 
the string "matte". A matte surface varies its reflection accord- 
ing to the orientation of the surface. In this case, the square is 
still colored uniformly because its orientation is uniform, but 
the importance of orientation sensitivity will become clear in 
the next example. 

Coloring the square 

The call to RiColorO before the polygon declaration affects all 
objects declared after it. The color declared here is a greenish- 
blue. Since Listing 2.1 did not declare a color, its square came 
out white ( color (1 ,1 ,1 )), the default color. 

The argument to RiColorO is an RtColor object, which is usual- 
ly a one-dimensional array with three elements specifying the 
proportion of red, green and blue in the color. These values 
should all lie within the range 0 to 1 inclusive: the color 
(1,1,1) is white, and (.l,.l,.l) a dark gray. 


22 


Chapter 2: Getting Started 


as^ - 





The picture resulting from this program shows just what we 
have described: a square, tilted and moved away from the 
viewer, with a greenish-blue color. 

About declarations and the graphics environment 

It is important for the routines affecting objects to be called be- 
fore the declaration of the relevant objects. If a polygon is to 
take on a certain color, that color must be specified before the 
polygon declaration. 

Viewing parameters and object color are part of the graphics 
environment maintained by the interface. Whenever a trans- 
formation, a color, a light source, or any similar attribute is de- 
clared, it becomes part of the environment. Whenever an ob- 
ject is added to a scene, any part of the environment relevant 
to that object (for the square, the color defined by RiCoIorO 
and the surface appearance defined by RiSurfaceO) "sticks" to 
that object. 

The environment is a set of standing attributes that apply to 
any relevant object. Rather than requiring the program to 
specify a separate color for each type of object, one routine ap- 
plies a color to every object. Declaring an attribute of the envi- 
ronment simply replaces the previous value of that attribute. 
Geometric transformations, though, are somewhat more com- 
plicated. Neither the rotation nor the translation above replac- 
es the previous transformation, but modifies it: the net effect is 
a rotation compounded with a translation. 

All attributes of the environment have default values set 
when the interface is initialized. The simplicity of the first 
two example programs can largely be attributed to that fact. 
However, the specification of the RenderMan Interface does not 
dictate the defaults for surface appearance or light source. In the 
first example, we used a surface that did not require a light 
source, and in the second we defined both a light source and a 
surface that used it 


A More Complex Object 

It is fairly easy to declare a square by directly describing its ver- 
tices. However, this kind of explicit description quickly be- 
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comes tedious for more complex objects. This section explores 
a few basic techniques for specifying objects more easily. The 
key idea is to use previously-defined, simpler objects to create 
more complex ones. Along the way, we think a bit more 
about geometric transformations. We also point out features 
of RenderMan that facilitate object description and placement. 

Defining a unit cube 

The main program in Listing 2.3 is similar to Listing 2.2. The 
translation is now by 1.5, and the call to RiPolygonO has been 
replaced by a new routine, UnitCubeQ. The previous program 
centered a 1-unit square on the 2 axis before moving it for 
viewing; this one centers a 1-unit cube on the coordinate ori- 
gin. 

There is not much to UnitCubeQ. It simply makes six calls to 
RiPolygonO, using the array Cube for data. Cube essentially 
contains six Squares at the various locations required to make 
up a cube. The problem with UnitCubeQ is that it is rather dif- 
ficult to read and understand, a troubling quality for such a 
simple object. How can this confusion be reduced? 

An alternative definition 

We begin with the observation that a cube is nothing but a set 
of squares in different positions and orientations. If those dif- 
ferences could be described easily, then the resulting object de- 
scription might be somewhat clearer. 

Listing 2.4 does that by redefining UnitCubeQ. Here, we are 
back to the old recognizable definition of the unit square. We 
use the Square array six times to declare six polygons. The dif- 
ference between them is that the last five are preceded by rota- 
tions that position the square at the six faces of the cube. 

This example shows another important characteristic of the 
RenderMan Interface: all declarations are conceptually call-by- 
value. The data in the Square array can be used to call RiPoly- 
gonO six times because the interface can be depended upon 
not to change it in any way. Any transformations or other 
changes are performed on a copy of the data. Similarly, the ap- 
plication program may freely change any arrays passed to an 
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#include <ri.h> 

static RtColor Color = [ .2, A, .6 


main() 

I 


) 


RiBegin(RI_NULL); A Start the Tenderer */ 
R*LightSource( "distantlight", RLNULL); 

RiProjection< "perspective", RLNULL); 
RiTranslate<0.0, 0.0, 1.5); 

RiRotate(40.0, -1 .0, 1 .0, 0.0); 

RiWorldBeginO; 

RiSurface( "matte", RLNULL); 

RiColor(Color); A Declare the color */ 
UnitCubeO; A Define the cube V 

RiWorldEndO; 

RiEndO; A Clean up after the Tenderer */ 


#define L -.5 
#define R .5 
#define D -.5 
#define U .5 
#detine F .5 
#define N -.5 


A For x: left side V 
A For x : right side */ 
A For y: down side */ 
A For y: upper side */ 
A For z: far side */ 
A For z: near side *f 


A UnitCubeO: define a cube in the graphics environment */ 

UnitCubeO 

{ 

static RtPoint Cube [6] [4] = | 

||L,D,F|, |R,D,F|, |R,D,N) |,|L,D,N(, A Bottom face V 


1; 

int i; 


|L f D,F), 

(R,U,N), 

|R,U,N), 

{R,D,F}, 

|L,U,N}, 


ILU,F) 1, |L,U,N|, 
(L,U,N), |L,U,F), 
|R,U,FJ, |R,D,F|, 
{R,U,F| },IL,U,F), 
{R,U,N} {R,D f N}, 


(L,D,N|, 
|R,U,F) I, 
|R,D,N| }, 
|L,D,F1, 
|L,D,N} } 


A Left face 
A Top face 
A Right face 
A Far face 
A Near face 


V 

V 

V 

V 

V 


for( i = 0; i < 6; i++) A Declare the cube */ 

RiPolygon( 4, R1 P, (RtPointer) Cube[i], RLNULL); 

I 

Listing 23 Defining a cube 


interface routine after it returns. The worlds on either side of 
the interface are completely separate. 
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^include <ri.h> 

P UnitCubeO: Enter a unit cube into the scene */ 
UnitCubeO 

l 

static RtPoint square[4] = { 

|.5,.5,.5), {-.5,.5,.5}, {-.5, -.5, .5], (.5, -.5, .5) 


P far square */ 

RiPolygon{4, RI_P, (RtPointer) square, RIJslULL); 

P right face V 
RiRotate(90.0, 0.0, 1 .0, 0.0); 

RiPolygon(4, Ri_P, (RtPointer) square, RIJvlULL); 

P near face */ 

RiRotate(90.0, 0.0, 1.0, 0.0); 

RiPoiygon(4, Ri_P, (RtPointer) square, RLNULL); 

P left face */ 

RiRotate(90.0, 0.0, 1 .0, 0.0); 

RiPolygon(4, RLP, (RtPointer) square, RLNULL); 

P bottom face */ 

RiRotate(90.0 / 1.0, 0.0, 0.0); 

RiPoiygon(4 / RLP, (RtPointer) square, RLNULL); 

P top face V 

RiRotateO 80.0, 1 .0, 0.0, 0.0); 

RiPolygon(4, RLP, (RtPointer) square, Rl NULL); 

I 

Listing 2.4 Alternative cube definition 


The rotation commands in Listing 2.4 highlight two subtle- 
ties. First, their effects accumulate: the third square is rotated 
by 180 degrees, not 90. The second, third and fourth squares 
are rotated about the y axis by 90, 180 and 270 degrees, respec- 
tively. The second subtlety is that the last two transformations 
might not appear to work: it seems at first that the fifth square 
would be rotated in y by 270 degrees, then spun in x by 90, 
leaving it as the left face, in the same position as the fourth! 
But the last transformation declared is performed first . The rotation 
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about x first brings the square to the bottom of the cube, and 
the other rotations leave it spinning, essentially unchanged. 
The net effect of the two x-rotations applied to the last square 
is to rotate it by 270 degrees before the y-rotations. 

A third definition 



Although this version of UnitCubeQ represents some im- 
provement in clarity, the rotations are still a little obscure; it 
takes some thought to predict what happens to the last couple 
of squares, since the last two transformations had to account 
for the transformations declared previously. Even this simple 
example illustrates the confusion that can arise from accumu- 
lating transformations. Listing 2.5 solves the problem using 
two new routines. RiTransformBeginO makes a copy of the cur- 
rent transformation from the environment when it is called, 
and a subsequent RiTransformEndO restores that copy into the 
environment, leaving the transformation as it was before. 
More precisely, RiTransformEndO restores the most recently 
saved current transformation. As a result, these calls can be 
nested, with several saves (pushes) occurring before a restore 
(pop). The transformation state after each pop will be the 
same as before the corresponding push. In other words, geo- 
metric transformations are stacked. 


The benefits of judiciously saving and restoring the current 
transformation are evident from Listing 2.5. We have en- 
closed the declarations of the first four faces of the cube in a be- 
gin/end transformation pair, making it possible to declare the 
top and bottom faces afterward in the most intuitive way: by 
declaring rotations in x. 



This procedure makes object declaration commutative, hence 
less error-prone. Since the environment is the same before 
and after every transformation pair, the three pairs here could 
be rearranged arbitrarily. 



Saving and restoring the transformation also eliminates side 
effects from the UnitCubeQ procedure. When the previous 
versions of the routine returned, the transformation was the 
one that moved the last face into place. Since the graphics en- 
vironment is globed within a program, returning from Unit- 
CubeQ would not restore the transformation to what it had 
been when the routine was called. Implicit side effects of pro- 
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^include <ri.h> 

/* UnitCube(): Enter a unit cube into the scene V 

UnitCubeQ 

i 

static RtPoint square[4] = i 

1.5, .5.5), 1-.5,.5,.5|, {-.5, -.5, .5), |.5,-.5,.5) 

I; 


RiT ransformBeginQ; 
t* far square V 

RiPolygon(4, RJ_P, (RtPointer) square, RLNULL); 
f* right face 7 

RiRotate(90.0, 0.0, 1.0, 0.0); 

RiPolygon{4, RI_P, (RtPointer) square, RLK'ULL); 

/* near face 7 

RiRotate(90.0, 0.0, 1 .0, 0.0); 

RiPoiygon(4, RI_P, (RtPointer) square, RI_NULL); 

l* left face 7 

RiRotate(90.0, 0.0, 1 .0, 0.0); 

RiPolygon(4, RI_P, (RtPointer) square, RI_NULL); 

RiTransformEndQ; 

RiT ransformBeginO; 

t* bottom face 7 
RiRotate(90.0, 1 .0, 0.0, 0.0); 

RiPolygon(4, RI_P, (RtPointer) square, R!_NULL); 

RiTransformEndQ; 

RiT ransform Begin(); 

I* top face 7 

RiRotate(-90.0, 1 .0, 0.0, 0.0); 

RiPolygon(4, RI_P, (RtPointer) square, R!_NULL); 

RiTransformEndQ; 


Listing 2.5 Another cube definition 
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cedures are a Bad Thing. Saving and restoring the current 
transformation eliminated that problem in UnitCubei). It now 
does only what is expected: define a unit cube centered at the 
coordinate origin. 


G 


Combining Objects 

Now that we have a satisfactory procedure for defining a 
scene with more than one object, we can experiment a bit to 
make a picture with a little more visual interest. 


A color cube 


The ColorCubei) function in Listing 2.6 defines a color cub-... 
in which the red, green and blue values of the cube vary with 
x, y and z, so that the near-lower-left comer is black and thc- 
far-upper-right comer is white. The color varies because the 
cube is composed of many smaller cubes stacked up in three 
dimensions, each given a color appropriate to its position. 
The number of minicubes on a side is given by the first pa- 
rameter to ColorCubei), and each minicube can be scaled to 
leave empty space between them using a scale factor given by 
the second parameter. The color cube defined here is, as be- 
fore, one unit on a side and centered about the coordinate ori- 
gin. 



ColorCubei) begins with RiAttributeBeginQ and ends with RiAt- 
tributeEnd(). These two routines are analogous to RiTransform- 
BeginO and RiTransformEnd(): they copy and restore, not just 
geometric transformations, but all other attributes of the 
graphics environment as well. Since these include the color 
reset by ColorCubei), this procedure eliminates side effects on 
the rest of the environment. 

The inner loop of ColorCubei) cycles n times through x, y and 
z, creating unit cubes, scaling them appropriately, then trans- 
lating them into position. The translation and scale com- 
mands at the beginning of the routine reduce the resulting 
cube to unit size and move the center of the cube to the coor- 
dinate origin. 
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#include <ri.h> 

/* 

* ColorCubeO: create a unit color cube from smaller cubes 

* Parameters: 

* n: the number of minicubes on a side 

* s: a scale factor for each minicube 

V 

ColorCubetn, s) 
ini n; 
float s; 

I 

int x, y, z; 

RtColor color; 

if( n<=0 ) 
return; 

RiAttributeBeginO; 

RfTransIate(-.5, -.5, -.5 ); 

RiScaie( 1.0/n, 1.0/n, 1.0/n); 

for{x = 0; x < n; x++) 
for(v = 0; y < n; y-f+) 
forlz = 0; 2 < n; z++) ( 

color[0] = ((float) x+1 )/ ((float) n); 
colorfl ) = ((float) y+1 ) / ((float) n); 
color[2] = ((float) 2 + 1 ) / ((float) n); 
RiColor( color ); 

RiT ransformBegin(); 

RiTransIate (x+.5, y +.5, z+. 5); 
RiScale( s, s, s); 

UnitCubeO; 

RiTransformEnd (); 

) 

RiAttributeEnd(); 


Listing 2.6 Defining a larger cube from smaller minicubes 


An alternative definition 

Now that we have a well-structured procedure for creating a 
color cube, we can improve its efficiency. The ColorCubeO of 
Listing 2.6 makes r? calls to UnitCubeO , each with six polygon 
definitions, five rotation commands, and three transforma- 
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tion save/restore pairs. This is not a complicated object; imag- 
ine the cost of defining an interesting scene! 

A quick glance back at the definition of UnitCubeQ reveals the 
real waste of all those procedure calls. Each cube is created ex- 
actly the same way, then modified by the calling procedure. It 
might be useful to create an abstract definition of an object 
such as a cube, and then make copies, or instances, of it. 

Listing 2.7 shows how the RenderMan Interface may be used 
to do just that. The new definition of ColorCubeO begins by 
creating an object description in the first three lines. The call 
to UnitCubeQ in the inner loop has been replaced with the 
routine RiObjectlnstance(), which creates an instance of the 
object, the cube created by UnitCubeQ. 

Here we see another begin/end pair: RiObjectBeginO and Ri- 
ObjectEndO. Between these calls, geometric primitives are not 
included in the scene when they are declared. Instead, each 
primitive is added to an internal object description. Once the 
object description is completed by calling RiObjectEndO, it 
may be copied to add objects to the scene. 

The object description is recalled using the RtObjectHandle re- 
turned by RiObjectBeginO. Every other detail of the representa- 
tion is hidden; the only use for an object description is to in- 
stance it by calling RiObject!nstance(). 

An object description is like a macro triggered by RiObjectln- 
stanceC). It is a particularly simple macro, though, because it in- 
cludes only geometric information: all other attributes in the en- 
vironment are applied when the object is instanced, not 
when it is created. This fact has its uses: we were able to create 
a set of cubes of different colors. It has the disadvantage that 
varying attributes like color inside the object (by, for example, 
issuing RiColorO calls within the object definition) is impossi- 
ble. 

A further restriction of object declaration is not apparent in 
Listing 2.7. The primitives inside the declaration must all be 
of the same type (i.e., polygons), and geometric transforma- 
tions are ignored. The version of UnitCubeQ used here must 
be the original one defined in Listing 2.3. 
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^include <ri.h> 

A 

* ColorCubeO: create a unit color cube from smaller cubes 

* Parameters : 

' n: fbe number of minicubes on a side 

* s: a scale factor for each minicube 

V 

ColorCube(n, s) 
int n; 
float s; 

I 

int x, y, z; 

RtColor color; 

RtObjectHandle cube; 

if( n<*=0 ) 
return; 

cube = RiObjectBeginO; 

UnltCubeO; 

RIObjectEndO; 

RiAttributeBegin(); 

R»Tran$lateK5, -.5, -.5 ); 

RiScale( 1 ,0/n, 1 .0/n, 1 ,0/n); 

for(x = 0; x < n; x++) 
forty = 0; y < n; y++) 

for (2 = 0; 2 < n; 2 ++} I 

colorfO] = {(float) x+1 ) / ((float) n); 
colorll] = ((float) y+1)/ ((float) n); 
color |2] = ((float) z+l ) / ((float) n); 

RiColor( color ); 

RiT ransformBeginO; 

RITranslate (x+.5, y+.5, Z+.5); 
RiScale( s, s, 5 ); 
RiObjectinstance(cube); 
RiTransformEnd (); 

I 

RiAttributeEnd(); 


Listing 2.7 A more efficient color cube 
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Summary of object creation 

We have just seen examples of the two basic paradigms for 
creating objects. First was the procedural paradigm, in which 
an object was created by calling a procedure. Second was the 
instance paradigm, which also required calling a procedure 
but was really using data, the object description. Choosing the 
appropriate method in particular circumstances is a matter of 
judgement, which is why RenderMan provides the choice. 

The important point is that both methods are hierarchical: 
they allow and encourage programs to build up complicated 
objects from more primitive ones. 


A Simple Animation 

Having defined a single image, we can move on to define a se- 
quence of frames, an animation. Listing 2.8 uses the Color- 
CubeQ routine to generate a series of pictures of a color cube. 
As the animation proceeds, the cube rotates, and the scale fac- 
tor applied to the minicubes goes to zero, so that over the 
course of the animation the small cubes disappear. 

Beginning the frame 

Everything outside the loop is unchanged from Listing 2.3. 
The call to RiDisplayO sends the output of the different frames 
to different files. Within the loop, the scene description is en- 
closed between a pair of new calls. The program calls RiFrame- 
BeginO with a frame number as argument to begin rendering 
a frame of the animation, and declares the frame finished by 
calling RiFrameEndO. 

The state of the geometric transformation is saved by RiFrame- 
BeginO and restored by RiFrameEndO. The program in Listing 
2.8 invokes RiRotateO NFRAMES times, yet each time the rota- 
tion occurs exactly as specified instead of compounding the 
earlier rotations. By contrast, the three calls that set up the 
viewing parameters are made only once, before the first 
RiFrameBeginO, because they are restored to the same state af- 
ter RiFrameEndO as before RiFrameBeginO. 
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^include <ri.h> 


^define NFRAMES 1 0 A number of frames in the animation */ 

^define NCUBES 5 A # of minicubes on a side of the color cube V 

#define FRAMEROT 5.0 A # of degrees to rotate cube between frames V 


main() 

f 

ini frame; 
float scale; 
char filename[20); 

RiBeginfRJ_NULL); A Start the Tenderer */ 

RiLightSource( n d istantl ight ,r f RI_NULL); 

A Viewing transformation */ 

RiProjection{ "perspective", R!_NULL); 

RiTranslate(0.0, 0.0, 1.5); 

RiRotate(40.0, -1.0, 1.0, 0.0); 

for (frame = 1 ; frame <= NFRAMES; frame++) I 
sprintf( filename, "anim%d.pic H , frame ); 

RiFrameBegin(frame); 

RiDispiay(tilename, RLFILE, RI_RGBA, R!_NULL); 
RiWorldBegin(); 

scale = (float)fNFRAMES-(frame-l )) /(float)NFRAMES; 
RiRotate(FRAMEROT-frame, 0.0, 0.0, 1.0); 

RiSurface( "matte", RI_N'ULL ); 

ColorCubefNCUBES, scale); A Define the cube */ 
RiWoridEndQ; 

RiFrameEndO; 


RiEndO; 


Listing 2.8 A simple animation 


Summary 

This chapter has provided the basic framework needed to 
make pictures: 

• initializing the RenderMan Interface. 
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• producing single frames and sequences. 

• inserting objects into a scene. 

• moving objects by declaring geometric transformations. 

• forming compound objects from more primitive ones. 

• modifying, saving and restoring the graphics environ- 
ment. 

• controlling the viewpoint of a scene. 

Chapter 3 addresses the overall design of the interface and pro- 
vides a more complete discussion of the basics. 


Summary 
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CHAPTER 3 


The Structure of a RenderMan 

Program 


n — j— f ace consists of a specific set of 



the definition of an optional 


I shading language. The coming chapters cover individ- 
ual calls, organized into groups according to domain (surface 
definition, viewing, shading, etc.). But first, there are some 
characteristics of the interface that apply across a variety of 
procedures: the idiosyncrasies of a procedural interface like 
RenderMan, the coordinate systems it uses, the syntax of pro- 
cedure calls, the data types used, and the overall structure of a 
RenderMan program. With this material in hand, the remain- 
ing chapters may be read in almost any order. 

This chapter develops a context for assembling RenderMan 
procedure calls into a RenderMan program, showing how 
they all fit together. At the end, a template program appears 
into which can be inserted the calls laid out in the coming 
chapters. A useful program for viewing typical scenes is devel- 
oped in Chapter 8. The one described here is most useful for 
grasping the structure of a RenderMan program; the latter is 
more practically oriented. 

RenderMan Procedures 

From the programmer's point of view, RenderMan consists 
entirely of procedure calls whose names begin with 'Ri' (for 
RenderMan interface). The user calls a procedure to add a sur- 
face to a scene or to modify a parameter. Depending on the sys- 
tem lying behind the interface, this data might be rendered 
immediately, archived for later rendering, sent off across a 
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network to a remote rendering server, or piped directly to a 
hardware Tenderer. 

Not all the routines in the interface are relevant all the time. 
Some routines, for example, address capabilities that some 
Tenderers do not provide. However, all Tenderers must define 
all RenderMan routines, even if they do nothing. This is to 
minimize changes required of a program using RenderMan 
from implementation to implementation. 

Error handling 

When an interface routine is passed detectably invalid data, 
or if the routine is inappropriate in a given context, it gener- 
ates an error condition. There are very few procedures in the 
RenderMan Interface that return any values at all, let alone er- 
ror codes. Rather, an error causes an action that is under the 
control of the application. 


RiErrorHandler( handler ) 

RtFunc handler; 

RiErrorHandierO specifies how to handle errors occurring in 
the RenderMan Interface, handler is a pointer to a routine to 
be is called when an error occurs. There are three handlers 
provided by the interface: RiErrorPrintO prints an error mes- 
sage to the standard error stream. RiErrorAbortO prints error 
messages, then aborts the program if the error is severe 
enough. Finally, RiErrorlgnoreO silently ignores all errors. If 
RiErrorHandierO is never called, RiErrorPrintO is called to han- 
dle errors. 

An application may define another error-handling function. 
It should be declared 

void MyHandJer( code, severity, message ) 

Rtlnt code, severity; 
char ^message; 

The code indicates the type of error, and severity is an index of 
its seriousness. Values for both are in the file ri.h , reproduced 
in Appendix C. message is a character string describing the er- 
ror. 
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An interactive rendering application might define an error- 
handling routine that called RiErrorPrintO, then queried the 
user whether to continue the program. An application that 
prefers careful error handling might post the error code and 
severity to a global error variable and return, letting the con- 
text of the error determine the appropriate action. 

Parameter lists 

Since RenderMan procedures are just subroutines, parame- 
ters are passed to them in the normal way. In the case of the C 
language binding, the RenderMan Interface supports a mecha- 
nism allowing the set of parameters passed to a given routine 
to vary: a variable-length parameter list. Syntactically, a pa- 
rameter list is a series of arguments in token-value pairs, ter- 
minated by a special token, RI_NULL. 

We already saw one such parameter list in Chapter 2. The call 
to create a four-sided polygon, 

RiPolygon(4, RI_P, (RtPointer)Square, RLNULL); 

has a parameter list that begins with the RtToken RI_P paired 
with the data in Square (cast to RtPointer), and ends with 
RI_NULL. A parameter list can include many such token-val- 
ue pairs, or none, but it must always end with RLNULL. 

Parameter lists provide syntactic flexibility. When a token ex- 
pected by a procedure does not appear, a default value may be 
used. Applications can therefore confine their attention to rel- 
evant features, and new features can be added to a routine 
without threatening existing programs. 

Not all parameters apply in all situations. The parameters rel- 
evant to a given procedure are included in its specification in 
this book. Some procedures require certain parameters. RiPoiy- 
gon(), for example, is meaningless without an array of verti- 
ces. Any required items will also be noted in the procedure 
specification. 

Not all RenderMan procedures take parameter lists. It de- 
pends entirely on the nature of the procedure. If a procedure 
does expect a parameter list, its declaration as it appears in this 
book will show the name parameterlist in italics as a pseudo- 
argument at the end of its argument list, parameterlist is 
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meant to stand for the whole R1_NULL- terminated list of pa- 
rameters. 

An alternative to parameter lists 

The use of variable-length parameter lists takes advantage of 
features of the C language that are sometimes considered dan- 
gerous or nonstandard. Some other languages (Pascal, for ex- 
ample) do not accept the idea at all. Therefore, RenderMan de- 
fines a vectorized version of each routine that replaces the pa- 
rameter list with an integer followed by two arrays. The first 
array contains tokens, and the second contains the values. For 
example, the call 

RiPolygon(4, RI_P. (RtPointer)Square, 

RI_N, (RtPointer)Niormals, RI_NULL); 

could be replaced with the fragment 

RtToken tokens)2); 

RtPointer values{2); 

tokenslO] = RI_P; 

values|0] = (RtPointer)Square ; 

tokens)!] = RI_N; 

values)!! = (RtPointer)Norma)s ; 

RrPolygonV{4, 2, tokens, values); 

The name of the vectorized version of each parameterlist rou- 
tine in the interface is obtained by appending 'V' to the unvec- 
torized routine name. Its calling sequence is the same, except 
that the parameterlist is replaced with a count and two arrays/ 
one of tokens and one of pointers. The count gives the num- 
ber of elements in each array. The vectorized routines will re- 
main implicit in the rest of this book. 

Data Types 

The RenderMan Interface defines a variety of data types that 
are always used for arguments and return values. In C, they 
are defined in the header file ri.h. Thus, any program file us- 
ing RenderMan types must include that header. 

The name of each data type begins with 'Rt' (for RenderMan 
type). Depending on the implementation, it may be possible 
to use the underlying types instead, but it is a good idea to use 
the defined types anyway. Their definitions may vary between 
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implementations, and non-rigorous use of types is flagged as 
an error by 'lint' and many C compilers. 

Scalar types 

typedef short RtBoolean; 

typedef long Rtlnt; 

typedef float RtFloat; 

typedef void RtVoid; 

typedef char “RtString; 

The usual scalar data types aie typedef 'ed to make them sub- 
ject to future revision. For RtBoolean variables, the constants 
RI_TRUE and RI_FALSE are predefined. RtStrings are used to 
pass names to shading language routines. 

Vector types 

typedef RtFloat RtPoint[3]; 

typedef RtFloat RtMatrix[4][4); 

typedef RtFloat RtBound[6]; 

typedef RtFloat RtBasis[4][4|; 

The RtPoint data type is used to pass three-dimensional geo- 
metric data through the interface. RtMatrix is used to specify 
linear geometric transformations as a 4x4 matrix. RtBound is 
used to supply three-dimensional bounding boxes for objects. 
RtBasis is explained in Chapter 6. 



Opaque data types 

typedef RtVoid 'RtPointer; 
typedef RtPointer RtObjectHandle; 
typedef RtPointer RtLightHandie; 

Sometimes data is passed through the interface, stored, and 
later passed back to the application. Other times, data returned 
to the application is later passed back in: light sources are 
turned on and off by passing an RtLightHandie data item, and 
retained models (discussed in Chapter 6) use RtObjectHandle. 
In both cases the internals of the data can and should remain 
invisible in the application. The data type RtPointer is used for 
these. 

When arrays of data are passed through the interface, they 
must first be cast to RtPointer, as in 

RiPolygon(nsides, R1_P, (RtPointer)vertices, RI_NULL). 
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£ Tokens 

typedef char 'RtToken; 

Whenever string identifiers are expected, RtTokens are used. 
For the strings already defined by the interface ("P", for exam- 
ple) RenderMan also defines, for each string, a constant that 
can be used in its place. These constant tokens may be used 
anywhere an RtToken can; they are named by a simple con- 
vention that capitalizes the name and prefixes it with 'Rl_'. 
Thus, the position token "P" becomes RI_P. The calls to RiPoly- 
gon() we have seen thus far could be replaced with 
RiPolvgon(nsides, (RtToken) ”P", (RtPointer) vertices, RI_NULL). 

Using predefined tokens rather than strings may enable some 
implementations to operate more efficiently. Their use is 
therefore advisable. Whenever a string is described in this 
book, the constant will also be provided. 

The line between RtTokens and regular character strings is 
sometimes indistinct. In general, an RtToken is used for any 
internal names, while a 'char *' is used for external references 
like file names. 

Function pointers 

typedef RtFloat (-RtFloatFunc)Q; 

typedef RtVoid (*RtFunc)(); 

RenderMan may, in some contexts, be passed functions to exe- 
cute later, as to RiErrorHandler(). These are passed either as Rt- 
FloatFunc, for functions returning floating-point values, or Rt- 
Func, for functions with no return value. 

Colors 

RenderMan has adopted a particularly flexible definition of 
"color," extending it beyond the usual RGB representation, 
typedef RtFloat RtColor[3]; 

The idea of multi-channel color values is essential to color 
graphics. The number of channels in a color is so often taken 
to be three (red, green and blue, for example) that one can be 
misled into thinking that there is some fundamental princi- 
ple decreeing that number. On the contrary, such color triples 
are just one way of describing light in the visible spectrum. 
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For other purposes (calculating the reflection of light from a 
surface, for example), more than three channels may provide 
a more accurate representation. 

By default, a color is represented in the RenderMan Interface 
by a triple of values representing the relative proportions of 
red, green and blue in the color. However, this number can be 
changed. 


RiColorSamples( N, nRGB, RGBn ) 

Rtlnt N; 

RtFloat nRCB[N][3], RGBn(3][N]; 

RiCoiorSamplesO sets the number of samples used to repre- 
sent and calculate colors to N. This routine tells the rendering 
system to begin treating type RtColor as though it were defined 

typeder RtFloat RtColor[N); 

After a call to RiCoiorSamplesO, all routines that take color val- 
ues, even in token-value pairs, will expect RtFloat arrays to 
contain N elements. 

The remaining arguments express colors in the new color 
space in terms of RGB. The argument nRGB to RiCoiorSam- 
plesO should be an iVx 3 matrix of floating-point values, 
which will multiply each N-sample color vector to obtain a 3- 
vector for RGB. Conversely, RGBn is a 3 X /V matrix to per- 
form the inverse operation. RGBn provides the ability to 
transform RGB values defined in the interface into the new 
color space. 


There is no reason that N has to be greater than 3. If a modeler 
prefers to operate in some linear trichromatic color space oth- 
er than RGB, it can call RiCoiorSamplesO with appropriate 
transformation matrices to change the space in which it speci- 
fies colors. A monochromatic space could also be defined. 

The ability to support different color spaces can produce more 
accurate colors, but it is not required by the interface. If a giv- 
en Tenderer doesn't support the capability, it simply converts 
all the colors it receives to RGB immediately upon input. 
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Graphics State 

To act consistently, a procedural interface like RenderMan 
must maintain certain information from one interface call to 
the next. In fact, most of the routines in the interface do noth- 
ing hut modify this graphics environment (also known as the 
graphics state): RiColorO, for example, changes the part of the 
state information governing surface color, known as the cur- 
rent color, RiRotateO modifies the current transformation, 
and so on. Almost every routine in the interface either de- 
clares a surface or modifies the graphics state. If any procedure 
modifies the graphics state, that fact is noted in its specifica- 
tion. 

The graphics state consists of three types of information, each 
associated with one of the levels of abstraction discussed be- 
low. At the highest level are characteristics associated with in- 
dividual Tenderers and not subject to user control. These are 
the capabilities of a Tenderer. At the next level down are state 
variables that are constant over an entire image, the options 
of the interface. Most specific are attributes, which are bound 
to individual objects and surfaces. 

Every option and attribute has a default value, which is why 
the minimal program in Chapter 2 could be so simple: the 
camera has a presumed configuration, the Tenderer produces 
a standard type of output image, etc. The only unyielding re- 
quirement for a program is to provide a scene to be rendered. 

Getting a handle on the difference between the types of state 
information and when they can be modified is essential for 
understanding the structure of a RenderMan application. 

Capabilities 

A Tenderer must fulfill certain requirements before it can be 
said to support the RenderMan Interface. It must provide 
each of the procedure calls in the interface, perform hidden- 
surface removal, and support a number of other features. 

However, the RenderMan Interface also posits specific capa- 
bilities providing functional power, which is not strictly re- 
quired for rendering, but is still nice to have if you can get it. 
The basic set of procedures includes routines that support 
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each capability. Every Tenderer must provide the routines, 
even if not the capability. These capabilities are the following: 

• Solid Modeling: performing set operations (like 'union' 
and 'difference') on the spaces enclosed by sets of surfaces. 

• Trim Curves: the ability to cut away parts of free-form sur- 
faces. 

• Level of Detail: the ability to select one of several repre- 
sentations for a model depending on its apparent size in 
the image. 

• Motion Blur "streaking" an object across an image as 
though it moved while a shutter was open. 

• Depth of Field: blurring objects differently according to 
their distance from the viewer. 

• Programmable Shading: support for the RenderMan Shad- 
ing Language. 

• Special Camera Projections: the ability to perform non- 
linear mappings from the world to the image plane. 

• Deformations: support for nonlinear geometric transfor- 
mations. 

• Displacements: the ability to handle distortions across the 
surface of a single object. 

Capabilities are considered to be part of the graphics state be- 
cause programs using the interface should work whether a 
given capability is provided or not. Thus, there is a well-de- 
fined action (usually doing nothing) whenever a capability 
not provided by the Tenderer is invoked. 

From the application's point of view, though, capabilities re- 
quire no action at all; they are determined entirely by the 
choice of Tenderer. 

Options 

At the next level of flexibility, options are elements of the 
graphics state that are associated with an image as a whole. 
The most important options concern the viewing parameters 
of an image: where the camera is placed, where it's pointing, 
its field of view, etc. Other options pertain to the output im- 
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age: its resolution and aspect ratio, the kind of data produced 
at each pixel, and so on. 

RenderMan provides a long list of options, discussion of 
which fills much of this book. Each one is controlled by the ap- 
plication calling a specific routine. One special routine is pro- 
vided to set options used by a particular implementation but 
not supported by the usual interface routines. 


RiOption( name, parameterlist ) 
char ‘name; 

A call to RiOptionQ controls the name option via the token- 
value pairs in parameterlist . The entire parameter list is associ- 
ated with name for use by the underlying Tenderer. The same 
mechanism that maintains the status of other options can 
therefore be used to communicate nonstandard ones. 


Attributes 

Finally, there are the components of the graphics state associ- 
ated not with an image as a whole, but with individual ele- 
ments of the image, the geometric primitives which appear in 
it. After such an attribute value is posted to the graphics state, 
each primitive passed through the interface is "stamped" 
with that value. The most typical attribute is color, as passed 
by RiCoIor(): once RiColorO is called, all subsequent surfaces 
are given that color. 

As with options, there is a procedure for passing nonstandard 
attributes. 


RiAttribute( name, parameterlist ) 
char 'name; 

RiAttributeO posts the attribute denoted by name to the graph- 
ics state, associating it with the token- value pairs of parameter- 
list Any particular attributes accepted are up to the implemen- 
tation; any attribute posted to an implementation that doesn't 
expect it is simply ignored. 
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Options vs. attributes 

In the structure of a RenderMan program, there are only two 
important distinctions between options and attributes: where 
they can be declared and whether they can be saved and re- 
stored. 

Since options apply to an image as a whole, every option in ef- 
fect for an image must have its final value before the first pixel is ren- 
dered. Since rendering may begin after RiWorldBeginO, all op- 
tions must have been set by then. Attributes may be modified 
at any time. 

As noted in Chapter 2, attributes may be saved by RiAttribute- 
BeginO, and restored by RiAttributeEndO. This save/restore 
mechanism is one example of the effects RenderMan has on 
program structure, a topic that can now be opened in detail. 

Program Structure: Blocks 

Almost all modem programming languages include the no- 
tion of blocks of statements, sections of code that are treated 
as a single entity* for some purpose. For example, the then 
clause of a conditional construct often consists of a series of 
statements grouped into a block that is syntactically consid- 
ered one statement. 

The RenderMan Interface also groups its procedure calls into 
blocks. These blocks are defined by pairs of routines, one of 
the form Ri...Begin() and another like RL.EndO. For example, 
RiAttributeBeginO saves the entire set of attribute values in 
the graphics state and RiAttributeEndO restores it, so a matched 
pair of RiAttributeBeginO/ RiAttributeEndO calls delimits an at- 
tribute block. A pair of calls to RiTransformBeginO and Ri- 
TransformEndO defines a transformation block: they establish 
a local coordinate system by saving and restoring the current 
transformation. 

RenderMan also uses blocks to denote modes of the interface. 
From the user's point of view, RenderMan has three impor- 
tant ones. The first mode is in effect before RiBeginO. This is 
essentially a null mode, since the interface has not been ini- 
tialized. After RiBeginO, options can be set, but no primitives 
may yet be declared. This is essentially an image definition 
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mode. Finally, inside a block delimited by RiWorldBeginO and 
RiWorldEndO, the image characteristics are frozen; options can- 
not be changed, and only calls that concern the scene itself are 
allowed: primitive declaration and attribute manipulation. 

A block begun by RiBeginO or RiWorldBeginO may not contain 
another of the same type: you may not call RiBeginO twice be- 
fore RiEnd(). This makes sense because each represents a mode 
switch, w’hich can only occur once. Some RenderMan pro- 
gram blocks, how'ever, do not have this restriction. An at- 
tribute block, for example, may properly contain another at- 
tribute block: they may be nested. This nesting is w^hat gives a 
RenderMan program the ability to support hierarchical object 
definitions. The nesting capability of a block is noted with its 
specification. 

Table 3.1, which ends this chapter, lists each routine of the 
RenderMan Interface and the types of block in w^hich it is val- 
id. 


RiBegin( name ) 

RtToken name; 

RiEndQ 

Every RenderMan program must begin with the call RiBeginO 
and end with RiEnd(). This is the main block of a RenderMan 
program. 

name allows selection, by name, of a particular rendering 
method, if the implementation provides more than one. The 
default renderer is selected by passing RI_NULL 

The main block is not nestable: it is an error to call RiBeginO 
twice before calling RiEnd(). 


RiWorldBeginO 

RiWorldEndO 

The geometric primitives of a scene are defined between calls 
to RiWorldBeginO and RiWorldEndO (a world block). When Ri- 
WorldBeginO is called, the application must have finished pa- 
rameterizing the image to be output. The Tenderer enters a 
state for sending the geometric data to be rendered into that 
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image. All options are frozen, and any option-setting routines 
called before the matching RiWorldEndO result in an error. 

Depending on implementation, rendering may begin when 
RiWorldBeginQ is called. But from the viewpoint of the appli- 
cation using the interface, rendering is complete by the time 
RiWorldEndO returns. All the scene data declared in the world 
block is processed and removed by that time. This makes it 
possible for successive world blocks in a single program to cre- 
ate different images. 

The world block may only appear inside the main block. Be- 
fore the world block, options and attributes may be modified 
and light sources may be declared, but no primitives may be 
passed. Within the world block, options are frozen but primi- 
tives may be declared. 

The world block may not be nested. 


Whatever the purpose of a block, a program must maintain a 
strict nesting. Every block must end before the end of any block 
containing it. That is. 


RiBeginO; 

RiWorldBeginQ; 

RiWorldEndO; 

RiEndQ; 


is correct, but 


RiBeginQ; 

RiWorldBeginO; 

RiEndO; 

RiWorldEndO; 


is not. This applies to nestable as well as non-nestable block 
types. Groups of RenderMan statements begun with RiAt- 
tributeBeginO and ending with RiAttributeEndQ are also consid- 
ered to be blocks, in that nesting must be strictly maintained. 
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RiAttributeBeginO 

RiAttributeEndO 

RiAttributeBeginO saves the current state of all attributes and 
RiAttributeEndO restores the last set of attributes saved. Thus, 
the attributes outside such a pair are immune to any changes 
made inside it. The attributes saved include the current trans- 
formation, so that, for example, 

RiAttributeBeginO; 

RiTransformBeginO; 

RiTransformEndQ; 

RiAttributeEndO; 
is redundant. 


RiAttributeBeginO/RiAttributeEndO calls may be nested arbi- 
trarily. The sequence 
RiAttributeBeginO; 

RiAttributeBeginO; 

RiAttributeEndO; 

RiAttributeBeginO; 

RiAttributeEndO; 

RiAttributeEndO; 

is perfectly legal. Much more will be said about the usefulness 
of saving and restoring attributes and transformations in 
Chapter 7 on hierarchical object definitions. 

Since options never change over the course of an image, they 
are not saved or restored with the rest of the graphics state. 
Only one routine, RiFrameBeginO, can' save options, and only 
RiFrameEndO can restore them. 

One more block type was used in the last chapter and requires 
elaboration here. A frame block is used to generate succes- 
sive, numbered frames of an animation; it occurs inside an 
RiBegin()/RiEnd() (main) block and it encloses an RiWorldBe- 
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gin()/RiWorldEnd() (world) block. It is primarily used to save 
the options of a program so that they may be changed from 
frame to frame. 


RiFrameBegin( number ) 

Rtlnt number ; 

RiFrameEndO 

Within the main block, several images may be rendered. The 
beginning of a frame is denoted by calling RiFrameBeginO and 
ended with RiFrameEndO. number gives a number to the 
frame. Frame blocks may not be nested. 

Within a frame block, several world blocks may appear in se- 
quence, perhaps to generate shadows and reflection maps be- 
fore rendering the image in which they are used. 


RiFrameBeginO saves all options, and RiFrameEndO restores 
them. As a result, any options that change from frame to 
frame can be put inside a frame block, and those that remain 
constant should be put outside. 

A word about data handles 

The block types above have one final effect: they provide 
scope to data handles. Just as the graphics state defined in an 
attribute block ends when the block ends, data handles created 
within a frame or world block become invalid when the block 
ends. For example, a light source created before RiFrameBe- 
ginO will still exist after RiFrameEndO, but one created after the 
RiFrameBeginO call will be deleted. Any scoping consider- 
ations will be included in the declaration of routines which 
create handles. 

Coordinate Systems 

In three-dimensional computer graphics, five different coordi- 
nate systems can be identified at different stages of the view- 
ing process. The RenderMan Interface gives names to these 
five, and also supports naming of other coordinate systems. 
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Figure 3.1 The three-dimensional coordinate systems of Render Man. Object 
space is giz*en by the current transformation when an object is declared. World 
space applies at the beginning of a world block. Camera space is relative to the 
camera. 


RenderMan coordinate systems 

Of the five coordinate systems predefined in the RenderMan 
Interface, three are three-dimensional spaces concerning the 
placement of objects and the camera. They are shown in Fig- 
ure 3.1, above. The remaining two are two-dimensional, relat- 
ing to coordinates in the image itself. 

RenderMan's predefined coordinate systems are as follows: 

• Object space: the coordinates in which an object is de- 
fined. When RiPoiygonO passes a vertex list, the coordi- 
nates of the vertices are in object space by definition. 

• World space: the "global" coordinate system of a scene in- 
dependent of the camera. The interface moves objects 
from object space to world space by applying the current 
transformation as defined inside the world block. 

• Camera space: a coordinate system with the viewpoint at 
the coordinate origin and the direction of view along the 
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positive z axis. Once in world space, objects are trans- 
formed into camera space via a transformation defined be- 
fore the world block is entered. 

• Screen space: a normalized coordinate system after the 
scene is projected onto a viewing plane. Usually the out- 
put image occupies the range [-1,+1] in screen space, al- 
though this can be changed to provide for non-square im- 
ages and skew projections. Camera space coordinates are 
transformed into screen space using a projection defined 
by RiProjectionO. 

• Raster space: a two-dimensional space in which the top 
left corner of the top left pixel of the output image lies at 
(0,0) and pixel corners lie at non-negative integer locations. 

Where defined 

Object space is simply the space of the raw points used to cre- 
ate geometric primitives, and raster space is determined solely 
from the resolution of the output image, a straightforward 
mapping from screen space onto the pixels of the image. Cam- 
era and world coordinates are more interesting. 

Throughout a RenderMan program, there is a current trans- 
formation affected by all geometric transformation routines. 
This is the transformation that is saved and restored along 
with the rest of the graphics state. 

Within a world block, a surface is declared by passing object 
space coordinates to a geometric primitive routine like RiPoly- 
gon(). The current transformation is applied to those object 
space coordinates to move the surface into its position in the 
scene. The object's coordinates within the scene as a whole are 
then said to be in world space. 

The current transformation is also used to define the camera 
transformation used to present the world for viewing. The 
distinction between the two uses is simple: when a world 
block begins, with RiWorldBeginO, the current transformation 
is accepted as the one to use for the camera and cleared for use 
in accumulating object-to-wOrld transformations. 

Using the current transformation for both processes allows an 
equally rich (in fact, identical) set of transformations to be 
used for both object and camera transformations. 
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Hider Selection 

Some systems running under the RenderMan Interface may 
offer a variety of hidden-surface elimination techniques, 
called hiders, which can be chosen to meet various rendering 
demands. The specification requires, however, that every Ten- 
derer offer at least three options. 


RiHider{ type, parameterlist ) 

RtToken type; 

RiHiderO makes a selection among different methods of re- 
solving conflicts at the image plane. There are three standard 
possibilities for type . : 

• “hidden" (RtyHIDDEN, the default): the Tenderer's standard 
hidden-surface elimination technique is used. 

• "paint" (RLPAINT): each surface is written to the image 
when it is added to the scene, without resolving hidden 
surfaces at all (the name derives from "painter's algo- 
rithm"). To produce a coherent image using the painter's 
algorithm, the farthest objects must be declared first. 

• "null" (RIJSIULL): hidden surfaces are not resolved at all 
and no output is produced. 

parameterlist is the usual list of token-value pairs. It is 
RLNULL for the three standard types, but may be used to pass 
parameters to nonstandard types. 


The "null" hider type is useful mainly for checking the validity 
of inpu t data. 

A Boilerplate RenderMan Program 

The program below more graphically summarizes the preced- 
ing discussion, illustrating what is going on at each stage in a 
program describing a scene to RenderMan. It may be used as a 
template for standard RenderMan programs, since its struc- 
ture applies to most situations. However, the viewing pro- 
gram in Chapter 8 includes a wider variety of controls. 
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■ 


■ 



#include <ri.h> 

render(nframes) /* Basic program using the RenderMan Interface V 
int nframes; 
i 

int frame; 

RiBeginO; /* Options may now be set V 

/* IMAGE OPTION SECTION: See Chapter 8 '/ 

RiDisplay( ... ); 

RiFormat( ... ); 


/* CAMERA OPTION SECTION: See Chapter 8 '/ 

RiClippingl ... ); 

Ri DepthOfField( ... ); 

RiProjectioni^perspective", RLNULL); /* The current irans-V 
/* formation is cleared so the camera can be specified. V 
RiRotate( ... ); /* These transformations address the */ 

RiTranslate( ... ); /* world-to-camera transformation m f 

... /* controlling placement and orientation of the camera. V 

for(frame = 1 ; frame <= nframes; frames) j 
RiFrameBegin( frame ); 

/' FRAME-DEPENDENT OPTION SECTION V 

/* Can still set frame-dependent options , camera xforms '/ 
RiWorldBeginO; /* SCENE DESCRIPTION SECTION: '/ 

/* The camera xform is now set: options are frozen V 

/* and rendering may begin. We are in world space. */ 

RiAttributeBeginO; /* Begin a distinct object V 

RiColor{ ... ); /' Attributes fit in here '/ 

RiSurface{ ... ); /'See Chapter J J V 

RiTransformBeginO; /~ See Chapter 7 */ 

RiTranslate( ... ); /' Object-positioning V 

RiRotate{ ... ); C commands (see Ch. 7) */ 

RiSphere{ ... ); /’ See Chapter 4 '/ 

RiPolygon( ... ); / M See Chapter 5 '/ 

RiPatch( ... ); r See Chapter 6 V 

RiTransformEndO: 

RiAttributeEndO; /* Restore the parent's attributes. '/ 
/* Other objects, other spaces */ 

RiWoridEndO; /* The scene is complete. The image is ren - '/ 
/~ dered and all scene data is discarded. Other scenes V 
/* may now be declared with other world blocks . '/ 

RiFrameEndQ; /* Options are restored. */ 

1 

RiEndO; 


Listing 3.1 The structure of a RenderMan program 


Hider Selection 
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Summary 

This chapter has touched lightly on a variety of topics that 

span the RenderMan Interface. Most of the rest of this book 

simply fleshes out the basic framework given here. In particu- 
lar, subsequent chapters: 

• go beyond polygons to the full set of primitive object types 
supported by the RenderMan Interface. 

• detail the full set of attributes included in the graphics en- 
vironment. 

• describe the extent of RenderMan's support for hierarchi- 
cal models. 

• provide full control over the camera used to capture 
scenes. 

• set out procedures for adding and controlling light sources. 

• give much more control over how objects can be shaded. 


Valid Contexts for RenderMan Procedure Calls 


Routine Name 

Outside 

lS 

6b 

» 

Frame 

World 

Alt rib. 

Xform 

Solid 

Object 

Motion 

Genera! routines: 










RiErrorHandlerQ 










RiDedareO 










Begin-end block: 










RiBeginO 

• 









RiEndO 

• 









Frame block: 










RiFrameBeginQ 


• 








RiFrameEndO 


• 








World block: 










RiWorldBegin{) 


• 

• 







RiWorldEndO 


• 

• 







Attribute block: 










RiAttributeBeginO 


• 

• 

• 

• 

• 

• 



RiAttributeEndO 


• 

• 

• 

• 

• 

• 



Transform block: 










RiTransformBeginO 


• 

• 

• 

• 

• 

• 



RiTransformEndO 


• 

• 

• 

• 

• 

• 



solid block: 










RiSolidBeginO 




• 

• 

• 

• 



RiSolidEndO 




• 

• 

• 

• 
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Valid Contexts for RenderMan Procedure Calls (coni' d) 

Routine Name 

2 

T3 

C 

w 

% 

s 

2 

"C 

£ 

u 

u 


W 

Ol 

c 

m O 


3 

O 

60 

o 

sa 

ra 

u 

1 

< 

O 

Vm 

X 

c 

w 

la 

O 

o 

s 

object block: 










RiObjectBeginO 


9 

• 

• 

• 

• 

• 



RiObjectEndO 


9 

• 

• 

• 

• 

9 



motion block: 










RiMotionBeginQ 


9 

• 

• 

• 

! • 

i 

9 



RiMotionEndO 


9 

• 

• 

• 

1 • 

• 



options: 






i 




RiFormatQ 


• 

• 


1 

i 




RiFrameAspectRatioO 


• 

9 



i 


\ 


RiScreenWindowO 


• 

9 


1 

I 

i 

1 


RiCropWindowO 


• 

9 







RiProjectionQ 


• 

9 


1 

i 




RiClippingO 


9 

9 



I 




RiDepthOfFieldQ 


9 

• 



| 

j 



RiShutterO 


9 

9 







RiPixelVarianceO 


9 

9 







RiPixeiSamplesO 


9 

9 







RiPixelFilterO 


• 

• 







RiExposureO 


9 

• 


i 





RiimagerO 


9 

• 







RiQuantizeQ 


• 

• 







RiDisplayQ 


• 

• 







RiHiderQ 


♦ 

• 







RiColorSamplesO 


9 

• 







RiRelativeDetailQ 


9 

• 







RiOptionO 


9 

• 







lights: 










RiLightSourceQ 


9 

• 

• 

• 

• 

• 


• 

RiAreaLightSourceO 


9 

• 

• 

• 

9 

• 


• 

attributes: 










RiAttributeO 


• 


• 

• 

9 

• 


• 

RiColorQ 


• 

• 

• 

• 

9 

• 


9 

RiOpacityO 


« 

• 

• 

• 

9 

• 


9 

RiSurfaceO 


• 

• 

• 

• 

9 

9 


9 

RiAtmosphereO 


• 

• 

• 

• 

9 

9 


9 

RilnteriorO 


♦ 

• 

• 

• 

9 

9 


9 

RiExteriorO 


• 

• 

• 

• 

9 

• 


9 

RillluminateO 


• 

• 

• 

• 

9 

• 


9 

RiDisplacementO 


• 

• 

• 

• 

9 

• 


9 

RiTextureCoordinatesO 


• 

• 

9 

• 

9 

• 


9 

RiShadingRateO 


• 

• 

9 

• 

9 

• 


• 

RiShadingJnterpolationO 


• 

9 

9 

• 

9 

9 


• 

RiMatteO 


• 

9 

9 

• 

• 

9 


• 

RiBoundO 


9 

9 

9 

• 

• 

• 


9 

RiDetailO 


9 

9 

9 

• 

• 

• 


• 


Summary 
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Valid Contexts for RenderMan Procedure Calls (cont'c 

) 

Routine Name 

Oulsidc 

Bcg./End 

Frame 

World 

i 1 
< 

Xform 

Solid 

Object 

Motion 

RiDetailRangeO 

RiGeometricApproximationO 

RiOrientationO 

RiReverseOrientationO 

RiSidesO 

RiBasisO 

RiTrimCurveO 

transformations: 

; RildentityO 
‘ RiTransformO 

RiConcatTransformO 
| RiPerspectiveO 

RiTransIateO 

RiRotateO 

RiScaleO 

RiSkewO 

RiDeformationO 

RiCoordinateSystemO 

RiTransformPointsO 

polygons: 

RiPolygonO 

RiGeneralPolygonO 

RiPointsPolygonsO 

RiPointsGeneralPolygonsO 

patches: 

RiPatchO 

RiPatchMeshO 

RiNuPatchO 

quadrics: 

RiSphereO 

RiConeO 

RiCylinderO 

RiHyperboloidO 

RiParaboloidO 

RiDiskO 

RiTorusO 
general objects: 

RiObjectlnstanceO 

RiProceduralO 

RiGeometryQ 

map-making: 

RiMakeTexture() 

RiMakeBumpO 

RiMakeLatLongEnvironmentO 

RiMakeCubeFaceEnvironmentO 

RiMakeShadow() 


• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

; 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

! • 

• 

• 

• 

• 

i . 

• 

• 

• 

• 

• 

* 

• 

• 

• 

• 

' • 

1 * 

| . 

• 

1 * 

i 

i • 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

! • 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

t 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

♦ 

« 

• 

• 

• 

• 

! 

. i 
• 

• 

• 

j 

• 

• 

• 

• 

• 

• 

• 1 

• 

• 

• 

• i 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 
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CHAPTER 4 

Primitive Surfaces I: 
Quadric Surfaces 



"Treat nature in terms of the cylinder , the 
sphere , the cone, all in perspective." 

— Paul Cezanne 

r The first three chapters presented RenderMan in the 
1 large by sketching out the process it represents. The re- 
mainder of the book is devoted to specifics, beginning 
here with the basics of scene description: creating surfaces. 
This and the following two chapters concern the primitive 
surfaces available from the interface. Everything visible in a 
scene is ultimately composed of these surfaces. 

The words "primitive" and "prime" are related; they describe 
a key property of RenderMan's design: primitive surfaces are 
simple enough that they cannot be broken into simpler primi- 
tives without discarding important intrinsic structural infor- 
mation. For example, a sphere could be broken into facets, but 
not without losing smoothness. In general, the coherence of a 
surface is often lost when it is subdivided. 

Three categories of primitive are available. Quadric surfaces, 
the subject of this chapter, are defined by quadratic equations 
in two-dimensional space. Spheres and cones are examples of 
quadrics. Polygons are surfaces whose boundaries are given 
by a connected series of line segments. Objects represented by 
polygons are often characterized by a faceted appearance and 
straight-edged outlines, as we will see in Chapter 5. Finally, 
parametric surfaces, described in Chapter 6, are free form 
polynomial curved surfaces. 
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Figure 4.1 Sir different quadric types (top left to bottom right): sphere , cone, 
cylinder, hyperboloid , paraboloid, torus 


The quadric surfaces of RenderMan are surfaces of revolu- 
tion, in which a finite curve in two dimensions is swept in 
three-dimensional space about one axis to create a surface, as 
in Figure 4.1. A circle centered on the origin forms a sphere. If 
the center of the circle does not lie on the origin, the circle 
sweeps out a torus. A line segment with one end lying on the 
axis of rotation forms a cone. A line segment parallel to the 
axis of rotation sweeps out a cylinder. The generalisation of a 
line-segment sweep creates a hyperboloid by rotating an arbi- 
trary line segment in three-dimensional space about the z axis. 
Finally, a parabola, defined by the equation z forms a pa- 
raboloid when swept about the z axis. 

Each type of quadric is defined in RenderMan with a single 
procedure call, discussed below. Listing 4.1 shows the program 
used to generate Figure 4.1. The axis of rotation is always the z 
axis, so here the quadrics are rotated about the x axis for better 
viewing. Each quadric routine has a sweep angle parameter, 
specifying the angular extent to which the quadric is swept 
about z. It is important to realize that sweeping a quadric by less 
than 360.0 degrees leaves an open surface . The hemisphere result- 
ing from a 180.0° sweep is a cup, not a solid ball cut in half. If a 
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i-V 




solid is required, then measures must be taken to dose the 
surface. These are discussed in Chapter 7 on composite objects. 


#inc!ude <ri.h> 

GoO 

( ShowQuadsO; 

1 

#define OFFSET 1.2 

ShowQuadsO 

I 

RtPoint hyperpti, hyperpt2; 

RiRotate( -90.0, 1 .0, 0.0, 0.0); 

RiTranslate( -OFFSET, 0.0, (OFFSET/2) ); 

RiSpherei 0.5, -0.5, 0.5, 360.0, RJ_NULL ); /* Declare a sphere V 

RtTranslate{ OFFSET, 0.0, 0.0 ); 

RiTransiate( 0.0, 0.0, -0.5 ); 

RiCone{ 1 .0, 0.5, 360.0, RI.NULL ); /* Declare a cone V 

RiTransiatei 0.0, 0.0, 0.5 ); 

RiTranslate( OFFSET, 0.0, 0.0 ); 

RiCylinder( 0.5, -0.5, 0.5, 360.0, RLNULL ); /* Declare cylinder V 

RiTranslate( -(OFFSETS), 0.0, -OFFSET ); 

hyperpti [0] = 0.4; 

hyperptl [1 ] = -0.4; 

hyperpti [2] = -0.4; 

hyperpt2[0] = 0.4; 

hyperpt2(1 1 = 0.4; 

hvperpt2[2] = 0.4; 

/* Declare hyperboloid */ 

RiHyperboloid( hyperpti, hyperpt2, 360.0, RLNULL); 

RiTranslate( OFFSET, 0.0, -0.5 ); 

RiParaboloid( 0.5, 0.0, 0.9, 360.0, RJ_NULL ); /* Declare paraboloid V 

RiTranslatef OFFSET, 0.0, 0.5 ); 

RiTorus( .4, .15, 0.0, 360.0, 360.0, RLNULL ); /* Declare torus V 


Listing 4.1 Routine generating quadric surfaces shown in Figure 4.1 
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Quadric Declaration Routines 


i 


J! 

as. 

a? 



*1* 

a 

a* 


:r 

-I 


RiSphere( radius, zmin, zmax, thetamax, parameterlist ) 

RtFioat radius; 

RtFioat zmin, zmax; 

RtFioat theta max; 

The parameters to RiSphereQ are illustrated at 
right, radius is the radius of the sphere, zmin and 
zmax may be used to cut off the bottom and top of 
the sphere. For example, a hemisphere opening ii 
2 can be declared by setting zmin to the same value as radius 
(meaning that the bottom is not cut) and zmax to 0. Normal- 
ly, the sphere runs from -radius to + radius in 2 . 

thetamax is the sweep angle of the sphere. As with every quad- 
ric, the sweep begins at the x,z plane and sweeps around the 2 
axis. If thetamax is 360.0, an entire sphere is swept out; if it is 
180.0, a hemisphere is swept out in positive y, and so on. 



RiCone( height, radius, thetamax, parameterlist ) z 

RtFioat height; 

RtFioat radius; 

RtFioat thetamax; 

The base of a cone declared with RiConeO rests on 
the x r y plane, with the z axis passing through the 
center of the base and the tip of the cone, as 
shown at left. The radius parameter refers to the 
radius of the base, and height gives the distance be- 
tween the base and the tip. As with all quadrics, thetamax may 
have some value other than 360.0 to sweep out some part of 
the cone. 



RiDisk{ height, radius, thetamax, parameterlist ) 
RtFioat height; 

RtFioat radius; 

RtFioat thetamax; 
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A disk is a special case of a cone with height 0. For 
a disk, the height determines the disk's displace- 
ment in z. 

In other words, the call 

RiDisk( height, radius, thetamax, R!_NULL ); 
is exactly equivalent to the sequence 

RiT ransform Begin(); 

RiTransIate( 0.0, 0.0, height ); 

RiCone( 0, radius, thetamax, RI_NULL ); 

RiTransformEndO; 



RiCyiinderf radius, zmin, zmax, thetamax, parameter! ist ) 

RtFloat radius; 

RtFloat zmin, zmax; 

RtFloat thetamax; 

RiCylinderQ declares an open cylinder with a given 
radius , an extent in z given by zmin and zmax , and 
a sweep angle given by thetamax . 



z 



point 7 


RiHyperboioid( pointl, potnt2, thetamax, parameterlist 
RtPoint pointl , point2; 

RtFloat thetamax; 

RiHyperboloidO creates a hyperboloid from the 
three-dimensional points pointl and point2 . The 
surface is defined by taking the line segment be- 
tween pointl and point2 and sweeping it thetamax 
degrees about the z axis. 


Cones and cylinders are special cases of hyperboloids. A cone 
is simply a hyperboloid with one point on the z axis and the 
other on the xp. plane. The call 
RiConed.0, 2.0, 360.0, R1_NULL); 
generates a cone of radius 1, height 2; so does 
RiHyperboloid(pointl ,point2, 360.0, RI JMULL); 
if pointl = {0.0, 0.0, 2.0} and point2 = (1.0, 0.0, 0.0}. 
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j 

T 




A cylinder is equivalent to a hyperboloid generated by a line 
segment parallel to the z axis. A cylinder with radius 1 and 
height 2 can be declared either with 

RiCylinderO.O, 0.0, 2.0, 360.0); 
or by calling 

RiHyperboloid(point1, point2, 360.0); 
with point! = { 1 . 0 , 0.0, 0.0) and point2 = (1.0, 0.0, 2.0). 

Curved hyperboloids 

Cones and cylinders have straight sides, which is not surpris- 
ing since hyperboloids are generated using a straight line. But 
the hyperboloid above has a curved profile. How can this be? 
From the two endpoints and midpoint of the line segment 
shown in the figure, there is a circle on the hyperboloid sw 7 ept 
about the z axis. Ever} 7 point on the line sweeps out one such 
circle to form the hyperboloid. The radius of each swept circle 
is equal to the point's distance from the z axis. Any line seg- 
ment with an interior point nearer the z axis than its end- 
points will sweep out an "hourglass" hyperboloid like the one 
shown. 

One important distinction of hyperboloids concerns the mean- 
ing of thetamax. Unlike the other quadric types, the sw 7 eep of a 
hyperboloid always begins wdth the line segment in three- 
space, not with a curve on the x,z plane. 

The image at right show r s one use of hyperboloids: generating 
a general surface of revolution. The bowling pin w 7 as created 
from a profile curve defined as a set of points in the two-di- 
mensional plane. This curve was rotated about the z axis to 
create the three-dimensional figure. 

Listing 4.2 shows the routine SurfORQ. It takes an array of 
points in two-dimensional space and the length of the array. 
For each adjacent pair of points in two-dimensional space, it 
creates a pair of points in the x,z plane of three-dimensional 
space, then calls RiHyperboloidO to create one band of the sur- 
face as a truncated cone. 

When rendered, the bottom of one hyperboloid mates perfect- 
ly wdth the top of the next. There is, however, a segmented ap- 
pearance to the pin's profile owdng to the exclusive use of hy- 
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perboloids. A smoother approximation to a curved surface 
can be obtained by using other quadrics as well. Faux and Pratt 
[FAUX80] present a method of assembling conic sections into 
curves with point and tangency constraints. But parametric 
surfaces, discussed in Chapter 6, are much more generally use- 
ful for describing curved surfaces. 



i 

£ 


typedef struct ( RtFloat x, y; ) Point2D; 

Surt'OR( points, npoints ) 

Point2D points!]; 
int npoints; 

( 

int pt; 

RtPoint point! , point2; 

RtFloat “ppl, *pp2, “tmp; 
pp! = point! ; 
pp2 = point2; 

/- 

* For each adjacent pair of x,y points in the outline description , 

* draw a hyperboloid by sweeping the line segment cefined by 
M those points about the z axis. 

V 

pp! [0] = pointsfOJ.y; 
ppim =0; 

ppl [2] = points[0].x; 
tor( pt = ! ; pt < npoints; pt++ ) | 
pp2[0] = pointsfptj.y; 
pp2[l ] = 0; 

pp2 [2 ! = points[pt].x; 

RiHyperboloid( ppl, pp2, 360.0, R1JMULL ); 

tmp = ppl ; pp! = pd2; pp2 = tmp; f Swap oo inters m f 

I 

) 



Listing 4.2 Using hyperboloids to create a surface of revolution 



Paraboloids 

A paraboloid is a surface of revolution based on the parabola, 
a curve in two dimensions consisting of all points that satisfy 
the equation z=ax 2 , where a is a constant. 


Quadric Declaration Routines 
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RfParaboloid! rmax, zmin, zmax, thetamax, parameterlist ) 

RtFloat rmax; 

RtFloat zmin, zmax; 

RtFloat thetamax; 

The extent of a paraboloid generated by RiParabo- 
loidO is limited by the arguments zmin and zmax. 

All parabolas have their tip at U=0,z=0); zmin and 
zmax determine where the paraboloid is cut off at 
the bottom and top respectively. In addition, the parameter 
rmax determines the width of the paraboloid at zmax. The 
width of the parabola is adjusted so that the parabola passes 
through the point (x -rmax, z =zmax), so increasing rmax wid- 
ens the paraboloid. 



x 


Due to its definition, a paraboloid must lie in positive z. 
Therefore, it is an error for zmin or zmax to be negative. 


Torus 

A torus is the 'donut” shape that results from sweeping a cir- 
cle not centered on the origin about the z axis. 


RiToru5(majorrad, minorrad, phimin, phimax, thetamax, 
parameterlist ) 

RtFloat majorrad, minorrad; 

RtFloat phimin, phimax; 

RtFloat thetamax; 

majorrad gives the distance between the center of 
the torus and the center of the circle being swept; 
minorrad gives the radius of -the circle; phimin and phimax 
give sweep angles around the circle, relative to the point at 
the outside extreme of the torus. For example, phimin^ 180.0 
and phimax= 360.0 result in a circular trough, thetamax con- 
trols the wedge of the donut swept out. 



VLadi Us 
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Example: a toroidal "wave" 

Figure 4.2 is an image generated by the program in Listing 4.3. 
It is a circular wavelike pattern generated by a series of tori of 
matched radius. The function TorusWaveQ takes a number 


#include <ri.h> 
include <stdio.h> 

Go() ( TorusWave( 5, 360.0 ); I 

A 

* TorusWave( nwaves, thetamax ): create a set of concentric "waves" using 
m a hemisphere in the middle and a set or n waves concentric semi-tori. 

* The sweep of the waves is given by the parameter thetamax. 

V 

Torus Wave( nwaves, thetamax ) 
int nwaves; 
float thetamax; 

( 

float innerrad, outerrad; 
int wave; 

if( nwaves < 1 ) ( 

fprintf{stderr, M Need a positive number of waves\n"); 
return; 

) 


A Divide the net radius TO among the waves and the hemisphere */ 
innerrad = 2/( 8.0*nwaves + 2); 

RiRotatei 90.0, 1.0, 0.0, 0.0 ); 

A Create the cap for the center of the wave V 

RiSphere( innerrad, -innerrad, 0.0, innerrad, thetamax. RLNULl ); 

outerrad = 0; 

for( wave = 1; wave <= nwaves; wave++ ) | 

A 

* Each iteration creates a downward-opening half-torus 

* and a larger upward-opening half-torus. 

V 

outerrad = outerrad + {innerrad * 2); 

RiTorus( outerrad, innerrad, 0.0, 180.0, thetamax, RI_NULL ); 
outerrad = outerrad + (innerrad * 2); 

RiTorus( outerrad, innerrad, 180.0, 360.0, thetamax, R!_NULL ); 


I 

Listing 4.3 Using RiTorusO to create a wavelike pattern 
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^ * 






Figure 4.2 Circular "wave" patten ? generated by abutting semi-tori 


of waves and a sweep angle, generating that many waves in a 
figure one unit in radius. A hemisphere caps the innermost 
wave. Figure 4.2 was created with nwaves - 4 and thetamax = 
250. 
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CHAPTER 5 



Primitive Surfaces II: 

Polygons 


r . Polygons are a simple, easy-to-use class of surface. The 
* squares in Chapter 2 were polygons, defined, like all 
RenderMan polygons, by a boundary given as an or- 
dered series of vertices. Each vertex is linked to :he next ver- 
tex by an edge, with the last vertex linked to the first. The edg- 
es are implicit; only the vertices are passed to RenderMan. 

This chapter describes four routines for declaring polygons 
singly and in adjoining groups to form polyhedra. In general, 
the ability of polygons to describe curved objects is limited by 
their flatness, so this chapter also covers a technique for reduc- 
ing this faceted appearance. However, we will see that it is no 
panacea; that fact provides the motivation for the general 
curved surfaces of Chapter 6. 


Basic Polygon Types 

Polygons are classified according to their topology. Since each 
vertex of a polygon may lie anywhere in three-dimensional 
space, the RenderMan definition of a polygon covers quite a 
bit of ground: a polygon could be planar or non-planar, con- 
vex or concave; there could be holes in its surface; and its ver- 
tex list could even double back in such a way that the surface 
intersects itself. In a planar polygon, all vertices lie in the 
same plane in three-dimensional space. The notion of convex- 
ity is conveyed by imagining a rubber band snapped around 
the polygon; if it follows the vertices, touching each one, the 
polygon is convex. Otherwise (if there are gaps between the 
band and some edges) it is concave. Both classes are illustrat- 
ed in Figure 5.1. Only concave polygons are self-intersecting. 
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In many cases, it is much easier for a Tenderer to handle pla- 
nar, convex polygons. While the more general polygons are 
j convenient to the user, that convenience is not without cost. 

Consequently, a trade-off must be made between utility and ef- 
;j ficiencv. RenderMan helps make the trade-off by providing 

two routines for declaring polygons. RiPolygonO, which we 
|j first encountered in Chapter 2, requires its input to be planar 

and convex. RiGeneralPolygonO allows planar concave poly- 
gons with holes. Even though some implementations may ac- 
cept non-planar polygons, RenderMan does not guarantee the 
results. 

The other two polygon declaration routines, RiPointsPoly- 
gons() and RiPointsGeneralPolygonsO, are similar, but allow a 
group of polygons that share vertices (a polyhedron) to be de- 
clared at once. 

Simple polygons 


RiPolygon( nvertices, parameterlist ) 

Rtlnt nvertices; 

RiPolygonO declares a single, convex, planar polygon with no 
holes. The polygon has nvertices vertices; the vertices them- 
selves are given in parameterlist, as a "P" (RI_P) token-value 
pair, the value of which is an array of nvertices points, each of 
type RtPoint. 
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The following examples using RiPolygonO show how poly- 
gons may be used to create a surface of revolution. Listing 5.1 
defines the function PolyBoidQ used to create a ring centered 
around the z axis, much like a hyperboloid. A single band is 
defined by two points in the x,z plane; when swept about the z 
axis, the line segment between the points sweeps out a band. 

In Listing 5.1, PolyBoidQ takes four parameters: pointO and 
point 7, which define the band, ndivs dictating the number of 
triangles used, and parity, which helps adjacent bands to mate 
correctly by providing a phase factor that aligns vertices with 
vertices. 

The image at left is a bowling pin composed of polygons, par- 
alleling the hyperboloid bowling pin in Chapter 4. PolyBoidQ 
is called repeatedly for successive pairs of points along the pro- 
file of the bowling pin, as RiHyperboloidO was there. 

Vertex Format and Information 

This bowling pin has some obvious flaws: its faceted appear- 
ance is that of many adjoining flat surfaces rather than a 
smoothly curved surface, and its profile consists of straight 
edges. 

Flat shading 

The situation depicted in the bowling pin arises because the 
polygons are flat shaded: each polygon has the same color at 
all points, and the color changes abruptly in passing over the 
edge from one polygon to another. One way to ease that prob- 
lem is to subdivide the object: use more, smaller polygons. 
The immediate result would be to reduce the magnitude of 
the transition from one to another. Eventually the polygons 
would be so small that you couldn't even see them individual- 
ly, much less notice the difference between them. 

This solution has at least two disadvantages. First, it multi- 
plies the amount of data that must be passed through the in- 
terface. This is even worse than it seems at first, since halving 
the average width of the polygons requires four times the num- 
ber of polygons (doubling horizontally and vertically) to cover 
the same area. The second disadvantage is that to avoid exces- 
sive subdivision, the extent of subdivision should be deter- 
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A 

' PolyBoidO: approximate a hyperboloid using triangles . 

* pointO, point! ; three-dimensional points as in RiHyperboloidQ 
' ndivs: number of triangles to generate 

' parity; phase factor (0 or 1) to mate triangles from adjacent bands 

V 

Po!yBoid(pointO, pointl ,ndivs,parity) 

RtFloat ’‘pointO, 1 ' point! ; int ndivs, parity; 

I 

RtPoint vertexpair0[2], 
vertexpair! 12], 

‘ptrnextpair = vertexpairO, 

■ptrlastpair = vertexpair!, 

"temp, 

triangle[3]; 

int i; 

^define SWAP(a,b,temp) temp = a; a = b; b = temp; 

^define COPY_POINT<d, s) fd!0]=s|0]; d!!]=si!]; d[2]=s[2];} 
getnextpair(0+parity/2.0 f ptrnextpair, pointO, point! , ndivs); 
for (i = ! ; i <= ndivs; i+-r) j 

SWAP(ptrIastpair, ptrnextpair, temp) 
getnextpair(i+parity/2.0, ptrnextpair, pointO, point!, ndivs); 
COPY_POINT(triangle|0], ptrlastpairjoj); 
COPY_POINT(trianglefl], ptriastpairflj); 
COPY_POINT(triangle[2], ptrnextpair[l ]); 

RiPolygon(3, R1_P, (RtPointer) triangle, RLNULL); 
COPY_POINT(triangle[Oj, ptrnextpair [0]); 
COPY_POlNT(triangle{! J, ptrnextpair!! )); 
COPY_POINT(triangle[2i, ptrlastpair!0]j; 

RiPolvgon(3, RJ_P, (RtPointer) triangle, RLNULL); 


i-define PI 3.! 4 159 

getnextpair(offset, ptrnextpair, pointO, pointl, ndivs) 
float offset; 

RtPoint ‘ptrnextpair; 

RtFloat ‘pointO/point! ; 
int ndivs; 

1 float r; 

double sin(), cos(); 
r = 2*PI*offset/ndivs; 
ptrnextpa ir |0] 10) = point0[0]*sin(r); 
ptrnextpa irI0)[l) = point0|0]*cos(r); 
ptrnextpa ir[0] \2] = point0[2); 
r = 2*PI*(offset-.5)/ndiv S ; 
ptrnextpair il)[0] = pointl (0]*sin(r); 
ptrnextpair!! )I1] = pointl I0)*cos(r); 
ptrnextpa i rl! ) [2] = pointl [2]; 

Listing 5,1 Polygonal approximation of a hyperboloid 
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mined by both the polygons' onscreen area and the magni- 
tude of the color change from one to the next. A bowling pin 
half the size of the one on the previous page would require 
one fewer binary subdivision, and if the lighting were flatter, 
fewer still. For a program to dynamically make the trade-off 
between data volume and picture quality, information would 
have to be passed back across the interface, seriously compro- 
mising the interface design. 

The basic problem here is that polygons are flat. As Figure 5.2 
shows, the orientation of a smoothly curved surface varies 
smoothly across the surface. If that same surface is approxi- 
mated using polygons, the orientation changes abruptly at the 
polygon edges. 

This is a problem because the orientation of a surface directly 
affects its appearance: a surface that faces away from a light 
source appears darker than one that faces toward it. In Figure 
5.2, the right polygon would appear brighter than the left one. 
Because the orientation changes abruptly at polygon edges, so 
does the shade of the object. 

The orientation of a surface is represented as a vector point- 
ing perpendicular to the surface (the surface normal vector), 
like those in Figure 5.2. It would make a polygonal object like 
the bowling pin appear much smoother if the surface normal 
used to shade the polygon varied in its interior as smoothly as 
it does for the underlying surface. This effect can be achieved 
by first associating the normal of the curved surface with the 





Figure 5.2 Smooth surfaces t>s. polygonal approximations 
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polygon vertices, then taking the normal at interior points to 
be a smoothly varying combination, or interpolation, of 
those at the vertices. This is the technique of Phong interpola- 
tion, named for Phong Bui Tuong. 

Listing 5.2 shows another version of the PolvBoidQ function, 
this time providing a suitable normal at polygon vertices. The 
surface normal is defined at each vertex in exactly the same 
way as position is: the token "N" (RI_N) is followed by an array 
of RtPoints, each giving a normal direction. The pin at right 
shows the result. The profile at the corresponding vertex is 
still segmented, but the shading is much smoother. 

In the bowling pin, each vertex position is used by several ad- 
joining polygons. This version of PolyBoidQ makes sure the 
normal vectors assigned to a vertex are the same for all the 
polygons sharing that vertex. Otherwise the shading of the 
surface would change abruptly from one polygon to the next. 

To correctly assign the surface normals to the polygon verti- 
ces, one must have some idea of the underlying surface. Fre- 
quently, a direct representation is not available. Here, for ex- 
ample, the bowling pin is represented by a series of profile 
points, with no information supplied about the profile be- 
tween those points. PolyBoidQ defines the normal at a profile 
point as a line perpendicular to a line segment between the 
surrounding two vertices (see Figure 5.3). PolyBoidQ takes that 
two-dimensional normal and sweeps it about the 2 axis just as 
it sweeps the vertex points themselves. 


A 



Figure 5.3 Normal calculation from adjacent vertices. The '‘surface” normal at 
vertex B is perpendicular to the line AC. 
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This is by no means the best or only method for approximat- 
ing the surface normals, but it emphasizes that such methods 
are only approximations. A common alternative is to calcu- 
late a vertex normal as the average real normal of the sur- 
rounding polygons. In any event, the important thing is that 
each vertex should have identical normals for each polygon 
sharing the vertex (unless, of course, a crease is really wanted). 

Drawbacks of polygons 

We have done about as well as we could with a polygonal ap- 
proximation to the bowling pin. Still, problems remain which 
are typical of the polygonal representation. To begin with, one 
can do little about the straight profile edge of this object. 

The second problem is a formal one: when a polygon has 
more than four vertices, the interior interpolation of such 
vertex values as color and normal is inherently ill-defined. 

Even for three- and four-vertex polygons, dramatic changes in 
appearance over the surface can make edges visible again. 
Since the eye is very good at picking out differences in the vi- 
sual field, even differences in the rate of change at edges are of- 
ten visible. Some of these artifacts can be seen in the smooth- 
shaded version of the bowling pin. 

Finally, it should be recognized that interpolation of normals 
is only an approximation because it interpolates vectors rath- 
er than angles (see Figure 5.4). Fortunately, the error is much 
smaller for relatively small changes in orientation. 



Figure 5.4 A linear interpolation between the two vectors does not interpolate an- 
gles linearly. The error is much smaller for srnall angles. 
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^include <ri.h> 

i : 

#include “surtor.h” 

rl 

include ‘'pin.hyper.h" 

■ 

RtColor color = i.9,.9,.5|; 

i! ; 

Co() { 

:r • 

RiColor(color); 





RiRotate{ -90.0, 1 .0, 0.0, 0.0 ); 
PolySurfORf points, colors, NPOINTS ); 



if! it 

* i : 

;ir ; 

ijj; 

-Ji= u 

i -ii 
.. ... 

• i 


PolySurtOR( points, colors, npoints ) 

Point2D points!]; 

RtColor colors!]; 
int npoints; 

{ 

int pt; 

RtPoint pointl, point2, normall, norma!2; 

RtFloat *pp1 , *pp2, *pm1 , *pm2, *tmp; 

ppl = pointl ; 
pp2 = point2; 
pml = normal! ; 
pm2 = norma!2; 

r 

* For each adjacent pair of points in the goblet description , 
draw a hyperboloid by sweeping the line segment defined by 
' those points about the z axis. 

V 


ppl )0] = points (OJ.y; 
ppl 11] = 0; 


'll 

ii 

ppl 12] = pointsIOJ.x; 

pml |0] = points[0].x - points! 1 ].x; 

f! 


pml [1] = 0; 

-I s 


pml [2] = points I l].y - points[0].y; 

n : 


for( pt = 1 ; pt < npoints-1 ; pt++ ) ( 

3 ■ 


pp2 [0] = pointslpt] . v; 

.*■ 

■* 

pp2 1 1 ] = 0; 


pp2[2] = points | pt] .x; 


t 

pm2|0] = pointsjpt-1 ].x - points [ptn- 1 ].x; 

!!•• 


pm2fl ] = 0; 

!: ; 

ii 

pm2[2] = pointslpt+l ].y - pointslpt-1 ].y; 

Si! » 

•j 

RiColor( colorslpt] ); 

i ill 

1 1 

PoiyBoid( ppl, pp2, pml, pm2, 8, pt-1); 

)*!•{ 

j 

tmp = ppl ; ppl = pp2; pp2 = tmp; 

Ih. 

ni:t 

1 

1 

^ tmp = pml; pml = pm2; pm2 = tmp; 

|i : *: 

♦ 

pt = npoints-1 ; 

2 i 

t 

f 

i 

Pp2fOJ ss points [ptj.y; 

1 

i 

PP^nj-O; 


pp2[2] = points[pt].x; 


41 T I 

*|t^ 

Ai'i 


j-i 


m 
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pm2[0] = points[pt-1].x - points[pt].x; 
pm2[l] =0; 

pm2[2I = points[ptj.y - points[pt-1 ].y; 
RiCoIor( coiors{pt] ); 

PoiyBoid( ppl, pp2, pml, pm2, 8, pt-1); 


PolyBandfpointO, point! ,normal0, norma! 1 ,ndivs,parity) 

RtFloat *point0,“point1 ,*norma!0, •normal 1 ; int ndivs, parity; 

1 

RtPoint vertexstrip(100]|21, normaistripfl 00] (2|; 
int i, nverts[1 00if2j, indices!! 00] [2] [3]; 

for (i = 0; i <= ndivs; i++) ( 

getnextpairn-fcpar!ty/2.0,vertexstrip[i],point0, pointl , ndivs); 
getnextpair(i+parity/2.0,normalstrip[i],norrnal0,normai1 , ndivs); 

1 

for (i = 0; i < ndivs; i++) j 

nverts [ i] [0] = nverts[i|(1 J = 3; 
indices[il!0ji0| = i*2; 
indicesfij [0) [ 1 j = i*2+1 ; 
indices!i|I0][2] = (i+1 ) ¥ 2+l ; 
indices! i} [ 1 ] [0] = (i+1)*2+1; 
indicesliimm = (i+l)*2; 
indicesfi] [1 ! [2] = i*2; 

I 

RiPointsPolygonsf ndivs*2, nverts, indices, 

RI_P, (RtPointenvertexstrip, 

RI_N, (RtPointer)normalstrip, 

R! NULL); 

1 

getnextpa i r(offset, ptrnextpa i r, po i n t0,poi n 1 1 , n d i vs) 
float offset; 

RtPoint * ptrnextpa ir; 

RtFloat *point0,*pointl ; 
int ndivs; 

I 

float r; double sinQ, cos(); 

r = 2*3.1 41 5 9 'offset/nd i vs; 
ptrnextpair[0]|0] = point0[0]*sin(r); 
ptrnextpair[0|[l | = point0(0|*co$(r); 
ptrnextpair[0|[2) = point0|2|; 

r = 2*3.1 41 59"(orrset-.5)/ndivs; 
ptrnextpair[1 1[0] = pointl (0}*sin(r); 
ptmextpair[l][l j = pointl [01*cos(r); 
ptrnextpair[1}[2] = pointl [21; 


Listing 5.2 Bowling pin with normals assigned to vertices 
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In summary, smooth shading can help reduce the shading ar- 
tifacts of the polygonal representation, especially if the poly- 
gons are relatively small, with little change of color and orien- 
tation. But it is a costly approximation: sometimes it takes 
thousands of polygons to approximate adequately a single 
smooth surface. It is much easier to define and manipulate 
curved surfaces directly. They are the subject of Chapter 6. 

Other polygon types 

RenderMan supports three other routines for defining poly- 
gons. One, RiGeneralPolygonO, allows a user to pass concave 
polygons with holes. RiPointsPolygonsO and RiPointsGeneral- 
PolygonsQ allow collections of abutting polygons (polyhedra) 
to be passed and stored efficiently. The four polygon routines 
can be arranged into a 2 x 2 matrix of capability, as below: 



One polygon 

Polyhedra 

Convex polygons, 
no holes 

Concave polygons 
with holes 

RiPolygonO 

RiGeneralPolygonO 

RiPointsPolygonsO 

RiPointsGeneralPolygonsO 


RiGeneralPolygon( n loops, n verts, parameterlist ) 

Rtlnt nloops; 

Rtlnt nverts[); 

A general polygon is defined as nloops loops, in contrast to 
the single loop of RiPolygonO. The first loop defines the out- 
side of the polygon, and the remaining nloops - 1 loops define 
holes. There should be nloops elements of nverts ; the fth ele- 
ment gives the number of vertices in the zth loop (see Figure 
5.5). In parameterlist there must therefore be 

nloops-l 

^ nverts [i] 

f=0 

RtPoint vertices in the "P" (RI_P) token-value pair of parame- 
terlist As with RiPolygonO, there must be an identical num- 
ber of vertex normals, colors or any other varying attribute, if 
they appear at all 
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nverts RI_P 



RLN 

— loop 1 

H • • • loop 2 

~ loop 3 


Figure 5.5 Parameters to RiGeneralPolygonO 


Polyhedra 

In the bowling pin example above, each vertex was used in up 
to six triangles, so each point was passed six times. The same 
was true of other attributes, like surface color and normal, as- 
sociated with the polygon vertices. In rendering, each point 
will require six times the storage and will be transformed six 
times as often as it strictly needs to be. 

This is a common situation when surfaces are assembled 
from adjoining polygons. The solution is to separate the defi- 
nition of a polygon from the definition of its vertices , i.e., to de- 
fine the points separately, forming the polygons by referring 
to the points. This is often dubbed the points-polvgons form. 

Two RenderMan routines support this strategy. As before, 
one accepts planar, convex polygons without holes and the 
other is more general. 


RiPointsPolygons( npolys, nverts, verts, parameterlist) 

Rtlnt npolys, nvertsU; 

Rtlnt verts []; 

RiPointsPoiygonsO defines npolys polygons; the first polygon 
has nverts[0] vertices, the second nverts[ 1], and so on. There 
must be 
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nloops-1 
y n verts [/] 

i=0 

elements in the array verts, each of which is not a point, but 
an index into the RI_P array in parameterlist. Since each ele- 
ment of verts is an index, it also serves to index arrays of other 
attributes. 


RiPointsPoiygonsO imposes a special meaning on the RI_P to- 
ken-value pair in parameterlist. There are only as many 
points as there are distinct vertices in the set of polygons. Each 
element of verts specifies a polygon vertex by indexing into 
that vertex array. For a polyhedron, where polygons share ver- 
tices, most vertices will be indexed more than once by verts. 
There is no limit to the number of polygons that can share a 
vertex. 

For example, the effect of the call 

RiPolygon( 4, R1_P, (RtPointer) square, RLNULL); 

can be reproduced using RiPointsPoiygonsO. If nverts has 1 ele- 
ment set to 4, and verts has 4 elements such that verts[i] = i, 
then the call 

RiPointsPolygons( 1, nverts, verts, RLP, (RtPointer) square, RLNULL); 
has the same effect. 

For a less trivial example, consider a cube. It has six polygons 
with four vertices apiece, but there are only eight distinct ver- 
tex positions. Thus a cube would be described to RiPointsPoiy- 
gonsO using a vertex array of eight RtPoints. npolys would be 6 
and nverts would have 6 elements, each set to 4. Finally, verts 
would have 24 elements. The first four would index, in the 
R!_P array, the vertices of the first polygon; the second four 
'Would index the second polygon's vertices, and so on. Figure 
5.6 shows the situation. 

Listing 5.3 uses RiPointsPoiygonsO in one more version of the 
PolyBoidQ function. Besides saving time and space, this ver- 
sion actually makes the resulting program cleaner. Using mul- 
tidimensional arrays for indices and nverts inside the pro- 
gram makes it a little clearer, and is immaterial to the inter- 
face; they are treated as single-dimension arrays, and it all 
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verts 

Figure 5.6 Parameters to RiPointsPolygonsO for a cube 


works out due to the row-major order of multidimensional 
arrays in C. 

There must be enough elements of the vertex (or any other) 
array in parameterlist that verts[i] does not exceed the array 
bounds for anv i. In other words, if mcixindex is the largest ele- 
ment of verts, then there must be at least (maxindex+l) ele- 
ments of the vertex array. 


#define MAXVERTS TOO 

/* 

* PolyBoidO: declare a polygonal '’hyperboloid" using RiPointsPolygonsO 

V 

PoiyBoid(pointO, point!, normalO, normal!, ndivs, parity) 

RtFloat *pointO, “point!, “normalO, *normal1; 
int ndivs, parity; 

( 

RtPoint vertexstrip(MAXVERTS][2]; 

RtPoint normalstrip[MAXVERTS] [2]; 

int i, nvertsfMAXVERTS] [2], indices[MAXVERTS][2][3); 
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npolys-l 

loopcount = ^ nloopsfp] 

p=0 


giving the number of elements of averts. Lastly, there should 
be 


loopcount - 1 

^ n verts [/] 
i= o 

elements of verts. As before, these index the array of RtPoint 
coordinates given in the RI_P parameter. Anv other variables 
bound to vertices should have exactly the same number of 
values, and they are indexed exactly the same way. Once 
again, the maximum index in the verts array must be strictly 
less than the size of the vertex array in parameterlist. 
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Primitive Surfaces III: 
Parametric Surfaces 



r This chapter concerns the most general curved sur- 
* face types in the RenderMan Interface. Polygonal mod- 
els are useful primarily for representing objects with 
flat surfaces. Quadrics take a first step toward representing 
curved bodies, but the range of shape they can take is still very 
limited. By contrast, parametric surfaces enjoy a great deal of 
flexibility while providing intuitive control parameters to 
make manipulating them fairly natural. 



The mathematical foundations of parametric surfaces are 
somewhat more sophisticated than those of polygons and 
quadrics. However, only a relatively small part of that back- 
ground is required in order to use them effectively. This chap- 
ter discusses the facilities of RenderMan for declaring para- 
metric surfaces, and provides several examples. Appendix B 
goes into the subject in more detail, providing a specification 
of how a wide variety of surfaces can be obtained from identi- 
cal geometry. The discussion here is considerably more accessi- 
ble. 

The RenderMan Interface provides two classes of parametric 
surface. Uniform surfaces, both bilinear and bicubic, are easy 
to use with a minimum of mathematical background and rig- 
or. Non-uniform rational B-splines (affectionately known as 
NURBs) are more flexible and general, but require a back- 
ground beyond the scope of this book. The discussion of 
NURBs is confined to describing the RenderMan routine sup- 
porting them, followed by references to more complete treat- 
ments. 
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Figure 6.1 Drawing a bilinear patch 


Uniform Bilinear and Bicubic Patches 

A single parametric surface, or patch, can be visualized as an 
elastic square in three-dimensional space that can be stretched 
and twisted by a user. Even its characterization as a square is 
subject to change, since any edge can be shrunk to nothing by 
making two comers coincide. 

RenderMan supports two types of uniform patch. A bilinear 
patch is a quadrilateral, not necessarily planar, formed by four 
vertices in three-dimensional space. Its surface is described by 
bilinear interpolation of the vertices' positions. 

Bilinear interpolation is a generalization of linear interpola- 
tion. In linear interpolation, a line is formed between two 
points pi and p2 and associated with a parameter u, which 
ranges from 0 at pi to 1 at p2. A point on the segment is associ- 
ated with a value of u as the sum (p2*(l— u) + p2*w). A bilinear 
patch is defined by four points, as depicted in Figure 6.1: as u 
sweeps out two opposite edges of the quadrilateral, the surface 
is formed by lines drawn between points on the opposite seg- 
ments with equal values of u. Equivalently, one can imagine 


86 


Chapter 6: Primitive Surfaces III: Parametric Surfaces 


J 




BBS 



Figure 6.2 Control hull and one possible resulting surface 


one of the edges sweeping along a path by moving its end- 
points along its two adjoining edges. 

The second type of uniform patch in RenderMan, the bicubic 
patch, is a more interesting curved surface. It is also four-sid- 
ed, but both its edges and its surface can be shaped more flexi- 
bly. 

A bicubic patch is described using a set of control points ar- 
ranged in a 4x4 geometry matrix, also known as the surface's 
control hull. Figure 6.2 shows a control hull and its associated 
bicubic surface. The control hull approximates, in some sense, 
the surface itself. Moving a point on the control hull changes 
the shape of the surface in a predictable way. 

To render a single bilinear or bicubic uniform patch using the 
RenderMan Interface, an application passes a geometry matrix 
through RiPatchO. As with polygons, parameters other than 
position may be associated with the comers of the patch and 
interpolated to points on the interior of the surface. 


RiPatchf type, parameterlist ) 

RtToken type; 

RiPatchO declares a single patch, type must be either "bilinear" 
(RLBIUNEAR) or "bicubic'' (RLBICUBIC). parameterlist must 
contain a token-value pair with an array of either four control 
points, for a bilinear patch, or sixteen, for a bicubic patch. 


87 



Uniform Bilinear and Bicubic Patches 


Three-dimensional RtPoint coordinates, denoted by the type 
token R1_P, are usually given for the control points. A height 
field, denoted by "Pz" (RI_PZ), has one z (height) value per ele- 
ment: x and y implicitly run from 0 to 1 in each direction, so 
that the first point has x-y = 0 and the last, x=y=l. In all cases 
the array should be cast to (RtPointer). 

Homogeneous coordinates may also be given, preceded by 
the "Pw" (RI_PW) type token, as an array of four-dimensional 
points. Homogeneous coordinates include a fourth variable, 
iv, in addition to x, y and z: the fth point is expressed as a qua- 
druple [ Xj yj Zj iv: ]. The surface is evaluated in four dimen- 
sions as [ X(u,v), Y(u,v), Z(u,v), W (u,v) ], but the surface points 
are given by 

X'(u,v) = X(u,v)/mu,v) 

Y(u,v) = Y(u,i!)/W(u,c>) 

Z '(u,v) = Z(u,u)/W(u,t>) 

Other values, like surface normal and color, may be declared 
at the comers of a patch, just as they may be at the vertices of a 
polygon. Unlike polygons, however, there are exactly four cor- 
ners of any patch, so there will be exactly four elements in 
each array of the token-value pairs. The values will be inter- 
polated across the resulting surface using bilinear interpola- 
tion. 


Patch example 

The code fragment in Listing 6.1 produced the patch shown in 
Figure 6.2. It uses the 4x4 geometry' matrix Patch. The control 
hull can be rendered by breaking the geometry matrix into in- 
dividual 2x2 quadrilaterals and rendering them as bilinear 
patches. 

Choice of patch type 

Bilinear patches are not as flexible as bicubics, but they offer a 
viable alternative to polygons. First, a bilinear patch does not 
have the constraint of planarity. Second, a bilinear patch may 
be more efficient to render than a bicubic one, and so would 
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yfinclude <ri.h> 

^define XO -1 
#define XI -.33 
^define X2 .33 
#define X3 1 

^define YO -.7 
^define Y1 -.1 
#define Y2 0.1 
#def ine Y3 0.7 

#define ZO -1 
#derine Z1 -.33 
^define Z2 .33 
#define Z3 1 

RtPoint Patch[4][4] = ( 

{ XO, YO, ZO}, { XI , Y2, ZOI, { X2, Y1 , ZO}, { X3, Y3, ZO), 

| XO, Y1 , Z1 }, ( XI , Y2, Z1 }, ( X2, Y1 , Z1 },( X3, Y2, Zl ), 

( XO, Y1, Z2), ( XI, Y2, Z2}, ( X2, Y1, Z2}, i X3, Y2, Z2}, 

( XO, YO, Z3}, 1 XI, Y2, Z3), 1 X2, Y1, Z3}, ( X3, Y3, Z3}}; 

PatchExampleO 

1 

RtPoint blpatch[2|[2]; 
int u, v; 

^define MOVE_PT( d, s) I d[0j=s[0]; d[1 ]=s[1 ]; d[2]=s(2J; } 

#ifdef PATCH 

RiPatchi RI.BICUBIC, 

RI_P, (RtPointer) Patch, 

RLNULL); 

#endif 

#ifdef HULL 

for( v = 0; v < 3; v++) ( 
tort u = 0; u < 3; u++) | 

MOVE_PT( bl patch [0] 10] , Patch(v](uj) 

MOVE_PT( bipatch(0][1 1/ Patchjvj [u+1 ]) 
MOVE_PT( blpatchfl ][0], Patch(v+1 }[uj) 
MOVE_PT( blpatchfl ][1 1, Patch (v-r 1 J[u-rl )) 
RiPatchi RLBIL1NEAR, 

R1_P, (RtPointer) blpatch, 

RI_NULL); 

I 

I 

rfendif 

1 

Listing 6.1 Declaring a single bicubic patch or nine bilinear patches 
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be natural for flat surfaces, or for approximating curved surfac- 
es that are sufficiently small that interpolation can make the 
surface look smooth enough; as in the example above, the ge- 
ometry matrix of a bicubic patch might also be rendered as a 
set of bilinear patches for preliminary tests of a scene. Third, 
they are usually more efficient to render than polygons. 
Fourth, interpolation is always well-defined across a bilinear 
patch; this is not true of polygons. 


Types of Bicubic Surface 

A control hull does not completely define a curved surface, in 
the sense that many different surfaces could reasonably result 
from any given control hull. For example, does the surface 
pass through, or interpolate, the vertices of the control hull, 
or does it merely approximate them? Does it interpolate all of 
the vertices, or just a subset? If it approximates the control 
hull, how close is the approximation, how closely is the sur- 
face drawn to the vertices? There are many potential types of 
curved surface within the bicubics. 

There are four types of uniform bicubic surface supported di- 
rectly by RenderMan: Bezier, B-spline, Catmull-Rom and Her- 
mite surfaces. Just as bilinear patches are a natural extension 
of the mathematics of straight lines to surfaces, bicubic patch- 
es are an extension of cubic splines. For simplicity, we will 
discuss the different types of bicubic patch in terms of the cor- 
responding splines. A spline is described using a geometry vec- 
tor of four control points, in contrast with the geometry matrix 
of sixteen elements used to produce a surface. 


Bezier splines 


A Bezier spline on four control points interpolates the first 
and last points; the inner two points govern the curve's direc- 
tion, or tangent, at the endpoints. In the diagram at right, the 
curve is tangent to the line segment AB at point A, and to DC 
at point D. Furthermore, the "inertia" of the curve at point A 
is determined by the length of AB, and likewise at D by DC. 
Bezier curves provide the user a great deal of control over 
shape. 
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B-splines 

B-splines are fully approximating; such a curve will generally 
pass through its control points only if several of them are at 
the same location. This makes B-splines somewhat more diffi- 
cult to control than interpolating splines, but they do yield a 
very smooth appearance. 

Catmull-Rom splines 

Catmull-Rom splines interpolate the middle two control 
points; the tangent at those points is parallel to the line be- 
tween the previous control point and the next control point. 
Catmull-Rom splines are very convenient because they auto- 
matically fit a curve or surface to a set of points. However, 
they may not always interpolate in the expected way. 

Hermite splines 

Like a Catmull-Rom spline, a Hermite spline interpolates two 
of its control points, in this case the first and third. However, 
Hermite splines are unique among the RenderMan types in 
that the other two points are not positions, but vectors that de- 
termine the tangent of the curve at the interpolated points. 
The first member of the geometry vector is a position, the sec- 
ond gives the tangent at that position. The third is another po- 
sition, the fourth another tangent. 

Not only the direction but the length of the tangent vector in- 
fluences the spline. Figure 6.3 illustrates the effect of varying 
that length on the resulting spline. As with the Bezier splines. 




Figure 6.3 Varying tangent vectors in Hermite curves 
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the tangent's length dictates the (curvature of the spline at the 
endpoints. 

The Hermite spline example indicates an important fact: the 
basis type not only controls how the geometry vector influenc- 
es the spline, but it also determines the semantics of the geome- 
try vector: it must meet the requirements of the basis. Thus, 
in the Hermite case the geometry vector must contain tan- 
gents as well as positions. 

Other spline types 

For other types of curve (for example, the Beta splines and 
Cardinal splines), other parameters may influence the curve 
besides points and tangents. The curve's "closeness" to the 
control polygon (its tension), is a common example of such 
control. One way to introduce such parameters (by modifying 
the basis matrix used) is discussed in Appendix B. Another 
method, one which only involves manipulating the spline's 
control points, has been developed bv DeRose and Barskv 
[DEROSE88], 

Curves into surfaces 

As shown above, a spline is determined by four control 
points. A bicubic surface is determined by sixteen, arranged in 
a 4 x 4 matrix. One can view that matrix as representing eight 
curves, four in one direction (the u direction) and four in the 
orthogonal ( v ) direction. The surface is a tensor product of 
the curves in the two directions: corresponding points on the 
fom - curves in the u direction are used to generate curves in 
the v direction or, equivalently, vice versa. 

For the purpose of passing bicubic surfaces to RenderMan, 
this characterization of the surface as the product of orthogo- 
nal curves is important for one reason: the selection of curve 
type to use on a patch is independent in the two directions. 
For example, one can use a Bezier curve in the u direction 
and a B-spline in the v direction. 

Selecting the bicubic patch type 

Describing a bicubic patch requires not only passing a geome- 
try matrix, but also specifying two basis matrices, one for the 
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u direction and one for the v direction of the patch. Basis ma- 
trices are predefined for each bicubic type, so using one of 
those types is as easy as setting the surface color. The basis ma- 
trix is an attribute of the graphics environment passed with 
the routine RiBasisO. The Bezier basis is the default, so if, as in 
Listing 6.1, a Bezier surface is desired. RiBasisO need not be 
called. 


RiBasis( ubasis, ustep, vbasis, vstep ) 

RtBasis ubasis, vbasis; 

Rtlnt ustep, vstep; 

typedef RtFloat RtBasis(4][4]; 

RtBasis RiHermiteBasis, 

RiCatmuilRom Basis, 

RiBezierBasis, 

RiBSplineBasis; 

RiBasisO sets the current basis matrices used to create uniform 
bicubic surfaces from geometry matrices. Every surface de- 
clared in the current environment after a call to RiBasisO will 
use ubasis as its basis matrix in the u direction and vbasis as 
basis in the v direction. 

ustep and vstep concern the "evaluation window" for a bicu- 
bic patch mesh (discussed in the next section). The following 
table indicates the correct step values for each of the pre- 
defined bicubic types. 


Basis 

Step Name 

r Value 

RiHermiteBasis 

RiCatmullRomBasis 

RiBezierBasis 

RiBSplineBasis 

RLHERMITESTEP 2 

RLCATMULLROM5TEP 1 

RLBEZIERSTEP 3 

RLBSPUNESTEP 1 


As elements of the graphics environment, the current basis 
matrices and step values are saved and restored along with 
other attributes. 
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Figure 6.4 Catmull-Rom surface generated by Listing 6.2 


Example patches 

Listing 6.2 below shows a code fragment that uses the same ge- 
ometry matrix as the previous example, but also specifies a 
Catmull-Rom basis. Figure 6.4 shows the resulting surface. 


#inc!ude <ri.h> 

DoCatmuliRomPatch(patch) 

RtPoint patch [4] 14]; 

{ 

RiBasis( RiCatmullRomBasis, RLCATMULLROMSTEP, 

RiCatmuIlRomBasis, RLCATMULLROMSTEP ); 

RiPatch( RLBjCUBIC, RI_P, (RtPointer) patch, R! NULL); 

) 

Listing 6.2 Generating a Catmull-Rom bicubic surface from the previous control 
hull 


Bicubic Patch Meshes 

Surfaces are not usually rendered singly. Normally they are 
declared by passing a two-dimensional array, or mesh, of ad- 
joining patches to RiPatchMeshQ. The motivation is similar to 
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that for RiPointsPolygon(). It is possible, and has the same ef- 
fect, to declare each patch in a mesh separately, but the concep- 
tual elegance and storage -efficiency of a mesh make it worth- 
while to maintain that representation. A mesh can consist of 
either bilinear or bicubic patches. 

A bicubic mesh can define much more complex surfaces than 
a single patch alone. Intuitively, a 4 x 4 control hull is limited 
in the amount of inflection it can describe. A patch mesh effec- 
tively allows an N x M control hull for arbitrary N and M. 

If the motivation for using a mesh is to create a more com- 
plex surface, then presumably the resulting surface should be 
smoothly curved. In that case, the smoothness at the bound- 
aries of the individual patches becomes an issue. The limita- 
tions and requirements for continuity at patch boundaries is 
an important quality of the different surface types. In general, 
the approximating surfaces like the B-splines are smoother in 
a mesh at patch boundaries. 

Before presenting patch meshes directly, we return for a mo- 
ment to the curve representation to discuss how a longer con- 
trol hull is represented and used to generate a curve. 

Longer curves 

Figure 6.5 shows a series of curves generated from identical 
control points but different basis matrices. The first four (left- 
most) points are those of the previous curve discussion. 

There are 10 control points for each curve in Figure 6.5. Even 
on this longer geometry vector, each point on the curve is still de- 
termined by exactly four control points. Each of the above curves 
consists of a series of segments, each one determined by an 
evaluation window of four adjacent control points. The first 
four control points describe the first segment of the curve, 
then this evaluation window shifts to the next series of four 
points. The appropriate shift in control points between seg- 
ments is an important attribute of a curve type. 

Bezier evaluation window 

Since a Bezier spline interpolates its first and last control 
points, if two segments are to join, then the last control point 
of one segment should coincide with the first control point of 


Bicubic Patch Meshes 


95 


S 






96 


Chapter 6: Primitive Surfaces III: Parametric Surfaces 


3; v- 



'-*L 

i: 

fr* 

£ 

4 

i-- 


the next. That is precisely the case here: the evaluation win- 
dow shifts by three control points from one segment of the 
curve to the next. The Bezier curve in Figure 6.5 consists of 
three segments, evaluated on points A through D, D through 
G and G through /, respectively. In general, N Bezier control 
points become l(N-l)/3j curve segments. 

Bezier splines are a graceful, intuitive curve formulation. 
However, care must be taken when developing a long series 
of control points. The transition between the first two seg- 
ments in Figure 6.5 (at vertex D) is smooth only because C, D 
and £ are colinear. If the last pair of control points on one 
curve segment are not colinear with the first pair of the next 
segment, the curve will have a sharp break where the seg- 
ments meet, as it does here at point G. 

B-spline segmentation 

The B-spline curve shown in Figure 6.5 is qualitatively the 
smoothest of the four. At the joint between segments, a B- 
spline segment is always smooth unless adjacent control 
points lie on the same point. The end of one segment coin- 
cides with the beginning of the next, the tangents are the 
same, and the rate of change in the tangent is consistent across 
the segment boundary. 

The window of evaluation of a B-spline shifts by one from 
one segment to the next. In this example, there are seven B- 
spline segments. In general, for N control points, there will be 
(IV— 3) segments. 

Catmull-Rom segmentation 

The Catmull-Rom curve in Figure 6.5 is smooth and unbro- 
ken from one end to the other. Since a Catmull-Rom curve 
segment interpolates, and is bounded by, its middle two con- 
trol points, its evaluation window must shift by one control 
point to connect adjacent segments. For N control points, 
there will be (N-3) curve segments. 

The smoothness of the Catmull-Rom curve is intrinsic: the 
tangent of the curve at a given control point is parallel to a 
line segment between the surrounding control points, wheth- 
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er that control point is the end of one segment or the begin- 
ning of another. 

Hermite segmentation 

Since a Hermite geometry vector comes in point-tangent 
pairs, the evaluation window of a Hermite curve shifts by two 
vertices between segments. The Hermite curve in Figure 6.5 
consists of (N-2)/2, or four, segments. 

Both the position and tangent of successive segments of a Her- 
mite curve coincide; therefore its smoothness is built in. How- 
ever, it is still qualitatively less graceful than the B-spline 
above. 

Defining surfaces with patch meshes 

The discussion above indicates the economy of declaring 
patch meshes rather than individual patches. For example, 
since adjacent B-spline curve segments share three control 
points, a long B-spline curve can be stored in about one- 
fourth the space of a series of separately-defined curves. A B- 
spline surface mesh fits into somewhat more than one-six- 
teenth the space of the equivalent patches. 


RiPatchMesh; type, nu, uwrap, nv, vwrap, paramelerlist ) 

RtToken type, uwrap, vwrap; 

Rtlnt nu, nv; 

RiPatchMeshO declares a surface composed of a number of con- 
tiguous patches, type may be RI_BICUBIC or RI_BILINEAR, as 
with RiPatchf). 

nu and nv give the number of control points describing the 
surface in the u and v directions, respectively. Each must be at 
least 2 for bilinear and 4 for bicubic patch meshes. The array of 
position coordinates in parameterlist (RI_P, RI_PZ, or R1_PW) 
must have nu*nv elements in v -major order: nu RtPoint 
points are given nv times. 

A surface can be made to wrap in the u direction, the v direc- 
tion, or both, by setting uwrap and/or vwrap to "periodic". Oth- 
erwise, they should be "nonperiodic". 
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Evaluation of patch meshes 

A patch mesh is evaluated into patches in a manner exactly 
analogous to the curve case, as illustrated in Figure 6.6. The 
first patch is evaluated using a 4 x 4 matrix of control points 
starting with the first element of the RI_P array of position co- 
ordinates. The evaluation window then shifts by nustep 
points in u (moves to the right in the picture) for the second 
patch, where nustep and nvstepjwere passed to RiBasisO. If the 
patch is not wrapped, this process continues until the leading 
edge of the evaluation window runs off the end of the row of 
control points after (nu-3)/ nustep patches. The evaluation 
window then moves down with a "carriage return," shifting 
in v by nvstep, and the process repeats. It terminates when the 
bottom edge of the evaluation window falls off the bottom of 
the mesh. 

In Figure 6.6, below, the window of evaluation is illustrated 
on a 10 x 7 Bezier patch mesh. It first travels the u direction, 
shifting by 3 after each patch mesh, until it reaches the end of 
the row. Then it shifts down by 3 points and begins a new 
row. The process continues until it runs off the bottom. 

A caveat 

It is an error to have extra control points in either direction 
when the step size is greater than one (for example, a Bezier 
patch mesh might have 6 control points). 
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Figure 6.6 Window of evaluation on a patch mesh (Bezier case) 


Bicubic Patch Meshes 


99 


e. A bicubic mesh example 

Listing 6.3 provides yet another way to describe a surface of 
revolution, with a bicubic patch mesh. It redefines SurfORQ, 
taking an array of points as a profile curve and declaring a 
bicubic surface from them. The major difference in this exam- 
ple from the previous versions (besides the fact that it em- 
ploys bicubic patches) is that it expects an array of Bezier con- 
trol points. These points are taken to lie in the x,z plane, and 
the third dimension is obtained by sweeping the curve about 
the z axis. The figure at right shows a bowling pin produced by 
this version of SurfORQ. 

Patch wrapping 

Often a bicubic patch mesh is used to represent a closed body 
like the bowling pin at right. In those cases, the mesh can be 
closed "manually" by making sure the first and last points 
and tangents match. An alternative, though, is to have the 
j Tenderer close the patch in either u or v by setting uwrap 

;j and/or vwrap to "periodic" instead of "nonperiodic". 

With wrapping in effect, the evaluation window for a surface 
continues to shift after its leading edge falls off the end of a 
row and/or column (see Figure 6.7). At that point, the win- 
dow wraps around to the beginning of the array in the appro- 
priate direction. Evaluation proceeds as long as the trailing 
edge of the evaluation window’ is within the set of control 
i points. 


if 



Figure 6.7 Patch mesh wrapping 
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#derine NU 1 3 
#define MAXNPTS 100 
"define F (.4142135 '4/3) 
float coerf[NU][2J = { 

11, 0 |, I 1, F ), | F, 1 ), | 0, 1 |, |-F, 1 1, i-1, F ), 

1 - 1/0 1, 1-1, -F |, |-F,-1 1 , ( 0,-1 LfF,l }, | 1,-F I, I 1,01 1 ; 


SurfOR(points, npoints) 

Point2D points!); 
int npoints; 

I 

RtPoint mesh[MAXNPTS][NU|; 

int u, v; 

/* coeff holds a matrix or coefficients for sweeping a point on the XZ 
' plane circularly around the Z axis , with the circle approximated by 

* 4 Bezier curves 

V 

for (v = 0; v < nooints; v++) | 

/* 

' Start at the upper left of the mesh. For each 
' control point on the circle being swept out , 

* rotate every point on the XZ curve into position 

V 

for (u = 0: u < NU; u++) ! 

/“ Here comes each point on the XZ curve ' ' 
mesh[v)(uj [0J = points[v).x “ coeff[ui!0|; 
meshivj[u)[1 1 = points[v].x * coeff{u][1 1; 
meshlvj[uj[2] = points[v).y; 

) 

) 

RiBasisf RiBezierBasis, RLBEZ1ERSTEP, RiBezierBasis, Rl_BEZ!ERSTEP ); 
RiPatchMesht RLBICUBIC, 

(Rtlnt) NU, RLNOWRAP, 

(Rtlnt) npoints, RI_NOWRAP, 

RLP, (RtPointer) mesh, 

RLNULU; 

i 

Listing 6.3 Version of SurfORO taking profile points and producing a bicubic 
patch mesh by sweeping them about the z axis 


Wrapped mesh example 

Listing 6.4 shows how the example from Listing 6.3 would be 
changed to use the wrapping feature of RenderMan. The only 
important difference is that the number of points in u is re- 
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#define MAXNPTS 100 
#define BEZ1ERWIDTH 12 

SurfOR(points, npoints) 

Poini2D points[J; 
int npoints; 

( 

RtPoint meshlMAXNPTS)[BEZIERWIDTH]; 

BezierSurfOR( points, npoints, mesh ); 
RiBasis( RiBezierBasis, R1_BEZIERSTEP, 
RiBezierBasis, R1_BEZIERSTEP ); 
RiPatchMesh{ RI.BICUBIC, 

(Rtlnt) BEZ1ERVVIDTH, RI_PERlODIC, 
(Rtlnt) npoints, RIJMONPERIODIC. 
RI_P, (RtPointer) mesh, RI_NULL); 


^define F (.4142135 '4/3) 
float coeff[BEZIERWlDTH]I2] = I 

n,0),(1,F|,|F, 1 1,10, 1 }, {-F, 1 ), {-1, F ), 
M,0), M,-F), {-F,-1 ),{0,-1 |,(F,4 }, M,-F) ]; 


BezierSurfOR{ points, npoints, mesh ) 

Point2D points!]; 
int npoints; 

RtPoint mesh[]|BEZIERWIDTH]; 

I 

int u, v; 

A 

* coeff holds a matrix of coefficients for sweeping a point on the XZ 

* plane circularly around the Z axis > with the circle approximated by 
' 4 Bezier curves. 

V 

for (v = 0; v < npoints; v++) 1 

A 

* Stan at the upper left of the mesh. 

* For each control point on the circle being swept out, 

* rotate every point on the XZ curve into position. 

V 

for (u = 0; u < BEZIERWIDTH; u++) { 

A Here comes each point on the XZ curve */ 
mesh!v)!u]f0] = points[v].x * coeff[u][0]; 
mesh!v][u][1 ] = points[vj.x * coeff[u]jl]; 
mesh|v]|u][2] = pointsfvj.y; 

I 


Listing 6.4 Defining c surface of revolution using a mapped patch mesh 
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duced by one, so that there are now 12 points in the u direc- 
tion. The thirteenth point for the fourth patch in a row is tak- 
en from the beginning of that row. We will use BezierSurf- 
ORQ again later on. 

General wrapping 

The appropriate number of points in a given direction for 
wrapping is also a function of the bicubic surface type. For the 
Bezier surface above, it is only sensible to omit the last point 
in u, which gives a position. For a wrapped Hermite patch, 
the number of points in the wrapping direction should be 
even, so that the last patch is sure to include both the position 
and tangent of the first point. 

The appropriate wraparound point cannot be determined a 
priori any more than the shift of the evaluation window for a 
given type of bicubic surface. Making sure that the mesh size 
is appropriate for wrapping is up to the application. 


Non-uniform Rational B-Spline Surfaces 
(NURBs) 

Non-uniform rational B-splines supported by RenderMan dif- 
fer in two important respects from the uniform, non-rational 
bicubic surfaces we have just presented. First, NURBs are 
based on B-splines; there is no notion of a basis matrix, and all 
control points are interpreted identically. Second, the bicubics 
are based on cubic polynomials; the degree of NURBs has no 
such constraint. 

Another distinction of NURBs concerns the parameterization' 
of the surface. NURBs allow, indeed require, an explicit speci- 
fication of the parameters that trace out the surface, in con- 
trast to the bicubic case, where we have avoided all concerns 
of parameterization. Where uniform surfaces are always eval- 
uated in their entirety, a non-uniform surface may be partial- 
ly rendered by giving a subrange of these parameter values. Fi- 
nally, for Tenderers that support the capability, parts of a non- 
uniform surface may be cut away in a more general fashion by 
declaring a trim curve in the parameter space of the surface. 
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NURBs significantly extend the possibilities of parametric sur- 
faces. For example, a sphere can be correctly represented using 
a NURB, but not with a bicubic surface. However, the theory 
and use of NURBs is beyond the scope of this book. For a very 
good presentation of this class of surfaces see the article bv 
Tiller [TILLER83]. 
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RiNuPatch(nu f uorder, uknot, umin, umax, nv, vorder, vknot, vmin, vmax, 
parameterlist ) 

Rtlnt nu, nv; 

Rtlnt uorder, vorder; 

RtFioat uknotl], vknot[); 

RtFioat umin, umax, 
vmin, vmax; 

For the it (v) directions the parameters are: 

• uorder (vorder): the degree of the polynomial plus 1. A cu- 
bic is therefore of order 4. 

• nu (nv): the number of control points (size of the mesh) in 
the u ( v ) direction. It must be true that nu > uorder and 
nv> vorder. 

• uknot (vknot): an array of knot values. The number of 
knots is nu+ uorder (nv+ vorder), and the knot values must 
appear in non-decreasing order within the arrays. 

• umin (vmm) and umax (vmax): the values of u and v defin- 
ing the parametric limits of the surface as evaluated. The 
values umin and umax must satisfy 

uknot uor der-i ^ umin < umax< uknot nu 

where the first knot is uknot o and the last is uknot UO rder+nu- 1 
(similarly for v). 

The parameterlist must contain an array of (nu*nv) points. If 
preceded with the type token "P" (RLP), each element must 
contain three coordinates. This will yield a non-rational poly- 
nomial surface. If the type token is n Pw n (RI_PW), four-vectors 
are expected and the surface will be rational. 
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A B-spline as a NURB 

If the basis matrices for uniform surfaces have been set to RiB- 
SpIineBasis by a call to RiBasisO, then the call 

RiPatch( RI_8ICU8IC, RI_P, (RtPointer)controlPts, RI_NULL ); 

is equivalent to the call 

RiNuPatch( 4, 4, knots, 0.0, 1 .0, 

4, 4, knots, 0.0, 1 .0, 

RI_P, (RtPointer)controlPts, R!_NULL ); 

for an arbitrary 4x4 array of points controlPts, if knots con- 
tains the values [-3, -2, -1, 0, 1, 2, 3, 4]. 

A uniform B-spline patch mesh on an nu x nv array of points 
could also be duplicated using RiNuPatchO by extending the 
above counts on the positive side and dividing by nu- 3. That 
is, knots would be 


[ — 
L nu-. 




-1 


3 nu-3 nu-3 


0 


nu-3 nu-2 nu-1 


nu 


nu-3 nu-3 nu-3 nu-3 



General Bezier surfaces from NURBs 

A bicubic Bezier surface will be produced from the same con- 
trol points if knots contains the values [ 0, 0, 0, 0, 1, 1, 1, lj. In 
fact, a Bezier patch of any degree can be expressed as a NURB. 
If the order is N, there should be N control points, and the 
knot vector should contain N 0's followed by .V l's. This is a 
very common way to provide Nth order Bezier patches. 

Further Reading 

Modeling with Bezier and B-spline bicubic surfaces is given a 
practical treatment in the book Curoes and Surfaces for Computer 
Aided Geometric Design [FARIN88]. A more theoretical, but ex- 
haustive, approach is taken by the book An Introduction to 
Splines for use in Computer Graphics and Geometric Modeling 
[BARTELS87], The classic introduction to NURBs is the article 
"Rational B-Splines for Curve and Surface Representation" 
[TILLER83]. 
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CHAPTER 7 

Geometric Transformations 
and Hierarchical Modeling 


r „ The last three chapters set out the types of primitive 
* surface accepted by the RenderMan Interface. Those 
primitives are the building blocks from which real ob- 
jects are built. The ability to combine simple objects into more 
complex ones is an important capability of modeling systems. 
This chapter describes RenderMan's approaches to the task. 
We begin with a discussion of just what hierarchical model- 
ing means, why it is so popular and what its limitations are. 
The following section, concerning the geometric hierarchy, in- 
cludes important digressions on the coordinate systems and 
orientation conventions of RenderMan. 


Concepts of Hierarchical Modeling 

Single patches, polygons and quadric surfaces don't have 
much inherent visual appeal due to their limited complexity. 
They usually become interesting only when grouped into ob- 
jects that more closely resemble things in the real world. In 
fact, henceforth we will use the term object to refer to a group 
of geometric primitives. A primitive object is just a single 
primitive, and an aggregate object consists of more than one. 

An object is a set of surfaces grouped together and treated as a 
single entity for purposes of shading, motion, duplication or 
assembling other objects. It is a conceptual convenience to 
think, for example, of a "cube" instead of "this square and that 
square and that square." But that is just a human interface is- 
sue, not necessarily relevant to the design of a rendering inter- 
face. From that standpoint, the best reason for supporting ag- 
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gregates is to simplify the job of assigning attributes. It makes 
sense to declare one color for the cube as a whole rather than 
having to assign colors to each face of a cube independently. 

The graphics environment of RenderMan supports aggregates 
implicitly: all objects declared between calls that modify the 
environment have identical attributes. For example, a call to 
RiColorO may be followed by the declaration of any number of 
squares, which consequently receive the same color. 

RenderMan's block structuring calls, discussed in the first 
chapters, strengthen this idea. In particular, RiAttributeBeginO 
and RiAttributeEndO are most often used to define a single ag- 
gregate. RiAttributeBeginO is followed by a series of attribute- 
setting procedure calls, then the primitive surfaces of the ag- 
gregate, all of which will have the same attribute values. 
When the corresponding RiAttributeEndO is reached, the at- 
tribute values return to their state before the block began. Ri- 
TransformBeginO and RiTransformEndO have a similar pur- 
pose in the geometric domain: each object defined inside a 
transform block has a common coordinate system. 

Hierarchical models 

Any aggregate object may be made part of another aggregate 
just as a primitive object can. In other words, blocks may be 
nested within one another. Thus, RenderMan supports a hier- 
archical model. A good example of a hierarchical model is a 
robot. It consists of a "body," two "arms," two "legs," and so 
forth, with a "leg" being composed of a "thigh," a "calf," a 
"foot," etc. The levels of an object hierarchy are often paral- 
leled by levels of abstraction: a door might consist of hinges, a 
wood panel, a doorknob and a lock. The lock could be de- 
scribed as a bolt, a cylinder, a keyhole, and so on. 

A hierarchy allows one to think of an object, a part, a sub- 
system in relation to another, larger object. For example, the 
hands of a clock in a space capsule would turn relative to the 
clock face. The clock itself is fixed inside the capsule, but the 
capsule may be tumbling through space as it rotates about the 
earth, which in turn is rotating about the sun. The absolute 
path of the hands of this clock is complex, but the hierarchical 
model breaks it down into a -few relatively simple motions of 
one object in relation to another. 
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Vocabulary 

In a hierarchy, the root is the highest level of abstraction. The 
root has one or more children, which may be leaves (prim- 
itive objects in the current context) or nodes (other hierar- 
chies) with children of their own. Two children of the same 
node are called siblings, and the node is their parent. There 
is an awkward mixing of metaphors here, but one can distin- 
guish the genealogical terms, denoting relationships, from 
the botanical terms for the parts themselves. 

Hierarchies and RenderMan 

The RenderMan Interface supports this hierarchical model by 
providing a graphics environment, geometric transformation 
scheme, and explicit support for solids modeling. Each type of 
hierarchical aggregate has a particular purpose. 

Graphics environment 

The graphics environment stack is implicitly hierarchical. 
Pushing the environment with RiAttributeBeginO is equiva- 
lent to starting a child of the object currently being declared. 
Any attributes of the environment that apply to the parent al- 
so apply to the child, unless they are explicitly modified dur- 
ing the description of the child. RiAttributeEndO restores the 
environment as it was originally, so that any subsequent chil- 
dren will share the unmodified attributes of the parent, rather 
than those of preceding children. 

Scene description 

The root of the object hierarchy is the entire scene being im- 
aged. Every surface and object is Contained within a "world ob- 
ject" because they are all declared in a world block bounded by 
RiWorldBeginO and RiWorldEndO. There is only one world at a 
time; world blocks cannot be nested. 

Geometric transformation environment 

As introduced in Chapter 2, geometric transformations are 
part of the general graphics environment, but there are also 
routines that save and restore the current transformation: Ri~ 
TransformBeginO and RiTransformEndO. Judiciously applied 
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geometric transformations encourage the use of local coordi- 
nate systems. For example, a robot arm can be made to rotate 
about a joint in the shoulder using a coordinate system placed 
in the center of the joint. The transformation environment is 
important enough to occupy its own section below. 

Solids modeling 

An extremely powerful hierarchical tool is the ability to use 
one object to modify the shape of another object. For example, 
a drilled machine part can be modeled as the undrilled part 
with a cylinder removed from it. This concavity would be dif- 
ficult to introduce any other way. In general, this process of 
Constructive Solid Geometry (CSG) defines an object by ap- 
plying set operators to the points in space inside other objects: 
a hole results from subtracting the cylinder from the rest of 
the part. An object may also be defined as the intersection of 
two other objects. 

Object duplication 

Finally, objects may be gathered into an independent descrip- 
tion by a block bounded with RiObjectBeginO and RiObject- 
End(). A program can duplicate, or instance, such a descrip- 
tion with a single routine call. We first saw this capability 
demonstrated in Chapter 2. 

The remaining three sections of this chapter expand on the 
last three of these block types. They provide the most useful 
of RenderMan' s facilities for defining hierarchical objects. 

Geometric Transformation Environment 

The RenderMan Interface provides a full set of capabilities for 
transforming object geometry within an explicit hierarchy de- 
fined by the geometric transformation environment. The 
most important use of a geometric hierarchy is to give each 
part of an object its own local coordinate system. 

The current transformation 

The RenderMan graphics environment includes, along with 
object color and other attributes, a current transformation. 
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Like any other attribute, it is applied to each object when the 
object is declared. Unlike those other attributes, however, rou- 
tines that affect the current transformation do not replace it, 
but modify it. This behavior, was demonstrated in Listing 2.5 
of Chapter 2. 

There are two ways to understand the idea of a current trans- 
formation. In one view, the current transformation acts like a 
stack, with the transformations comprising it applied in re- 
verse order. The transformation declared last is applied first. 

On the other hand, one can view a new transformation as ap- 
plying directly to the coordinate system in which objects are 
defined (object space). In this model, the world begins with a 
set of coordinate axes, and any object is declared with geomet- 
ric coordinates relative to these axes; a quadric surface is al- 
ways ratationallv symmetric about the z axis, for example. 
When a new transformation is declared, it is applied to the co- 
ordinate axes. Objects will now be declared relative to these 
new axes. The coordinate system of the new object differs 
from that of its parent by the latest transformation. 

It might help to think of the coordinate axes as a three-dimen- 
sional cursor, with the transformation commands serving as 
directives to move the cursor. "Concatenate a transformation 
to the current transformation" is equivalent to "Transform 
the cursor." 

Under the latter model, RiTransformBeginO has the effect of 
retaining the coordinate system (or "cursor") in effect when it 
is called. RiTransformEndO disposes of all coordinate systems 
("cursors") defined in the meantime and restores the retained 
one. 


RiTransform8egin( ) 

RiTransformEnd( ) 

RiTransformBeginO saves a copy of the current transforma- 
tion, and RiTransformEndO restores it. Transform blocks, de- 
limited by these routines, may be nested. 
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RiAttributeBeginO and RiAttributeEndO also save and restore 
the current transformation. They do the same for the rest of 
the graphics state, though, which is a waste of effort if only 
the transformation changes inside the block. 

Geometric transformations in RenderMan 

The routines described below all affect the current transforma- 
tion. Their descriptions include an indication of whether they 
modify or replace it. 

Translation 

y 

===== - , A 

RiTranslatet dx, dy, dz ) 

RtFloat dx> dy, dz; 

RiTranslateO concatenates a translation onto the 
current transformation. Subsequent objects are 
moved by dx in x, dy in y and dz in 2. 


= - - ----- ■ - . = ~*-x 

Rotation 

Objects can be rotated about an arbitrary' axis that passes 
through the coordinate origin. 


RiRotatel angle, dx, dy, dz ) y 

RtFloat angle, dx, dy, dz; 

RiRotateO concatenates a rotation onto the cur- 
rent transformation. The axis of rotation is the 
ray from the origin through the point {dx, dy, dz). 

The angle parameter is expressed in degrees. Un- 
der a left-handed coordinate system (the default), 
if the thumb of the left hand is pointed along the 
axis from the origin to {dx, dy, dz), the fingers curl 
to point in the direction of positive rotation. A 
right-handed system reverses the direction. 
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Scaling 

Objects may be scaled in x, y and z independently. 



RiScale( sx, sy, sz ) 

RtFloat sx, sy, sz; 

RiScaleO concatenates a scale transformation to the 
current transformation; all x coordinates are multi- 
plied by sx, y coordinates are multiplied by sy, and 
z coordinates by sz. The figure to the left shows 
RiScalef 1.0, 0.5, 1.0). 


Skew transform 

A skew transform skews points in the world by an angle be- 
tween two orthogonal direction vectors. 


RiSkew( angle, dxl , dyl , dzl , dx2, dy2, dz2 ) 
y RtFloat angle, dxl, dyl, dzl, dx2, dy2, dz2; 

RiSkew() skews subsequent objects, (dxl, dyl, dzl) 
and (dx2, dy2, dz2) define two orthogonal vectors 
through the coordinate origin. The transformation 
skews the world so that the point (dxl, dyl, dzl) is 
z skewed angle degrees toward the point (dx2, dy2, 

dz2). The figure to the left shows the effect of 
RiSkewf angle, 0.0, 1.0, 0.0, 1.0, 0.0, 0.0). 

x 


Figure 7.1 on the next page shows the effect of a skew trans- 
form on the bowling alley scene. 

Perspective transform 

Although a perspective transformation is usually used in a 
camera specification, it can also be concatenated onto the cur- 
rent transformation anywhere. 
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RiPerspective( fov ) 

RtFloat fov; 

RiPerspectiveO concatenates a perspective transformation on- 
to the current transformation. The perspective transforma- 
tion defines a pyramid with apex at the origin of the current 
coordinate space, opening along the positive z axis, with oppo- 
site sides diverging at the angle fov , the field of view. Points 
within the viewing pyramid before perspective have x and y coordi- 
nates between - 1 and +1 afteiivard. Any points on the x,y plane 
cause a zero divide. 


Figure 7.2 shows the effect of a 90° perspective transform on a 
cube that has been translated along the z axis. Four rays from 
the origin on the left through four corners of the cube form a 
pyramidal volume whose opposite sides diverge at a 90° an- 
gle. The cube is one unit across and one unit down the 2 axis, 
so the near cube face fits perfectly inside this projection. 

After the perspective divide, the rays are parallel and form a 
box enclosing points that have x and y between -1 and +1. No 
matter what the width of the pyramid defined by fov, it always 
forms the same box after perspective. Any points inside the 
pyramid before the perspective are inside the box afterwards. 
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Figure 7.2 A cube before (left) and after (right) a perspective transformation 
with tbv=9Q ° 


On the right, the right-hand face of the cube has shrunk rela- 
tive to the left; it has become foreshortened with distance 
from the origin just as it would if viewed from there. 

The right-hand cube has also moved to the coordinate origin, 
because the perspective transformation affects z as well as x 
and y. Points between the near and far dipping planes (dis- 
cussed with RiClippingO in Chapter 8) are normalized by per- 
spective so that a point on the near plane has a z value of 0 af- 
ter perspective, and a point on the far plane lies at z=l. The 
dipping planes used by RiPerspectiveO lie at z=l and z=°°, so 
the near face of the cube goes to 0. The fact that the cube still 
has substantial depth after perspective indicates the perspec- 
tive transformation's extreme non-linearity: a farther cube 
would be much flatter after perspective. 

Perspective transformations cause division by 0 for points at 
z=0, and they give bizarre results for points in negative z. 
Therefore, they should be used with great care. 

General linear transformation 

In addition to the standard transformations above, more gen- 
eral transformations can be declared as either a transforma- 
tion matrix or a general procedure for transforming points. 


ns 
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RiConcatTransform( transform ) 
RtMatrix transform; 
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RiConcatTransformO concatenates the transformation speci- 
fied by the transform matrix onto the current transformation. 
An RtMatrix is a 4 x 4 homogeneous transformation matrix of 
RtFloat values. 


For example, 

RiScale; si , s2, s3 ); 
is exactly equivalent to 
RiConcatTransforml t ); 

if 

‘ si 0 0 0 
0 s2 0 0 
t= 0 0 s3 0 
0 0 0 1 

The matrix t must be passed to RiConcatTransformO in row- 
major order: [ s7 0 0 0 0 s2 0 0 0 0 s3 0 0001]. 

Clearing the current transformation 

The geometric transformation environment helps to build a 
"world" of objects defined with respect to a coordinate system 
independent of any particular camera description. The cur- 
rent transformation, whatever it may be, transforms each ob- 
ject into this universal coordinate system, this world space. 
When RiWorldBeginO is called, the object-to-world transfor- 
mation represented by the current transformation is "cleared" 
to the identity transformation. Therefore, in the absence of 
any transformation commands, all objects are defined in 
world space. 

If, during the scene description, it is necessary to define an ob- 
ject directly in world space, the current transformation may be 
reset to the identity using RildentityO. 
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Ri!dentity( ) 

RildentityO clears the current transformation. It does not affect 
any saved transformations; RildentityO may be enclosed in a 
transformation block so that the block's RiTranstormEndO will 
restore the previous transformation despite any intervening 
RildentityO call. 


A more general transformation 

RildentityO effectively returns the local coordinate system to 
world space, if used inside the world block, or camera space, if 
used outside. If some other specific space is desired, RiTrans- 
formO can establish it. 


RiTransform( transform ) 

RtMatrix transform; 

RiTransformO replaces the current transformation with the 
transformation specified by the transform matrix. RtMatrix is a 
4x4 homogeneous transformation matrix of RtFloat values. 


Calling 

RiTransformO t ); 

is equivalent to the sequence 

RildentityO ); 
RiConcatTransform( t ); 


General nonlinear transformation 

If the ability to apply an arbitrary linear transformation isn't 
sufficient, RenderMan also allows any other transformation 
at all to be programmed as a procedure and applied to object 
geometry. 


RiDeformation( name, parameter! ist) 
char 'name; 

An arbitrary deformation of space can be written as a shader 
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vising the RenderMan Shading Language. Once defined, the 
shader is invoked as a transformation by calling RiDeforma- 
tion() with name giving the name of the shader. As usual 
with shaders, parameterlist is a series of name/value pairs 
supplying parameters to the shader. The shader is called for 
each point in space that needs to be transformed. The set of 
points that are actually transformed depends on the imple- 
mentation. The shader will move the points according to the 
deformation. 
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The deformation expressed by the shader passed to Ri Deforma- 
tionO is conceptually the same as any other transformation. 
Naturally, it cannot be put on any matrix-based transforma- 
tion stack, but RenderMan guarantees that it is applied just as 
if it were. As a result, deformations and regular transforma- 
tion commands can be freelv intermixed. 

A deformation specified with RiDeformationO is applied to 
space as a whole. RenderMan also provides the capability to 
warp different parts of an object differently; this is also based 
on a shader, a displacement shader. 

In- and out-facing surfaces 

At this point, we pause to discuss some of the subtleties of the 
RenderMan geometric facilities: the interpretation of surfaces 
when they are assembled into objects, the conventions used 
to define those surfaces, and the nature of the coordinate sys- 
tems used bv RenderMan. 

J 

We have talked about objects as assemblies of surfaces. In gen- 
eral, the objects are abstractions a renderer knows little about 
because it has no way of knowing a priori whether a surface is 
part of a closed object. Even then it may be difficult to deter- 
mine which side of a surface faces the inside of an object. 

This information is important because many Tenderers can 
work more efficiently if they can discard surfaces obscured by 
the rest of the object they help to bound. If a surface is part of 
a solid object (i.e., the object is closed rather than open), and it 
is on the side of the object opposite the viewer (it faces away, 
in other words), then the object itself obscures the surface if 
the object is opaque. Any such surface can therefore usually be 
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discarded without further ado. This will also be true of parts of 
any curved surfaces that overlap the object profile. 

Most knowledge about whether a surface is part of a larger ob- 
ject, and whether the object is open or closed, translucent or 
opaque, is not explicitly passed through RenderMan. The key 
question is: is the surface only visible when it "faces toward" 
the viewer (that is, is it one-sided)? RenderMan depends on 
the user to supply that information. 


RiSides( nsides ) 

Rtlnt nsides; 

RiSidesO specifies the number of visible sides of subsequent 
surfaces. RiSidesO) declares that they are visible only on the 
"outside" (the forward facing side) and may be discarded oth- 
erwise. RiSides(2) declares both forward and backiacing surfac- 
es important, so none are discarded. These are the only legal 
values of nsides . 


Orientation 

If an application is to take advantage of this feature, it must 
ensure that forward and backfacing surfaces can be recognized 
as such by the renderer. The convention used by a renderer 
for this decision is simple: the inside and outside of a surface 
are defined by its surface normal, which is assumed to point 
to the outside of the object. A surface is facing the viewer if 
and only if the surface normal points toward the camera. 

For the renderer to use the normal correctly, the user must en- 
sure that the surface normal points in the "righr" direction by 
defining the surface properly. Quadric surfaces are defined so 
that normals point outward. The normals of other surfaces 
are defined in a straightforward way that arises from a simple, 
consistent coordinate system. 

Left - vs. right-handed coordinates 

The default coordinate system in the RenderMan Interface is 
the camera coordinate system, which is left-handed: the posi- 
tive x, y and z axes point right, up and forward, respectively. 
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Figure 73 Left- and right-handed coordinate systems 
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There is a simple mnemonic for remembering the relation- 
ship between the axes of a left-handed system. If the thumb of 
the left hand is pointing in the positive direction along one 
axis, the fingers curl in the direction of "wraparound" alpha- 
betical order: If the thumb points along x, rotation is from y to 
z; if along y, z to x; along z, x to y. In a right-handed system 
the same mnemonic holds using the right hand (see Figure 
7.3 above). 

The handedness of the coordinate system extends to paramet- 
ric surfaces: with the appropriate hand rotating from u to V on a sur- 
face, the thumb points along the surface's normal vector. For exam- 
ple, in a left-handed system the normal to a parametric sur- 
face points toward the viewer when the surface is oriented 
with the u and v axes pointing right and down, respectively 
(see Figure 7.4). Similarly, the parameter space of a quadric is 
defined to obey the handedness rule in exactly the same way 
for both left- and right-handed systems. Finally, when the 
hand turns around the vertices of a polygon in the order they 
are declared, the thumb points along the normal. In other 
words, the normal of a polygon points toward the viewer 
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Figure 7.4 Left-handed normals for primitive surface types 



when the vertices appear to be in clockwise order in a left- 
handed system and counterclockwise in a right-handed one. 

The user may explicitly set the handedness of the RenderMan 
coordinate system by calling RiOrientationO. 


RiOrientation( orientation ) 

RtToken orientation; 

orientation should be either "lh“ (RI_LH) / to set the orientation 
of subsequent surfaces to be computed using a left-handed 
rule, or "rh" (RI_RH), for a right-handed rule, orientation is an 
attribute of the graphics state and so is saved and restored by 
RiAttributeBeginO and RiAttributeEnd(). 


A change in orientation turns subsequent surfaces "inside 
out," so that they must be defined with the opposite handed- 
ness. RiOrientationO should generally be called only if the us- 
er knows that subsequent surfaces will obey the opposite con- 
vention. 

A geometric transformation (such as a scale) can change the 
handedness of a coordinate system implicitly by reversing the 
sense of its axes. In Figure 7.3, corresponding left- and right- 
handed examples differ only in that one axis is reversed. For 
example, the transformation command RiScale( -1 .0, 1 .0, 1.0) 
would turn the top left coordinate system into the top right 
one. 

When a linear transformation which changes the handedness 
is specified, RenderMan detects it and automatically compen- 
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sates so that the left-handed system is retained from the user's 
point of view. If the user wishes to force a change of handed- 
ness (perhaps to turn a primitive inside-out), it should be 
done with RiReverseOrientationO to avoid interfering with 
the tracking mechanism. 


RiReverseOrientationf ) 

The sense of subsequent surfaces is toggled between left- and 
right-handed and so flips normals from their previous sense. 


RiReverseOrientationO should be used with care, because a sub- 
sequent RiTransformEndO can remove any number of trans- 
formations which changed the sense of the coordinate system. 
The system will correctly track these, but the RiTransform- 
EndO will not compensate for the sense-reversal of RiReverse- 
OrientationO, since it is an attribute. 

This is a good place to use RiAttributeBeginO and RiAttribute- 
EndO instead, since the orientation is an attribute and RiAt- 
tributeEndO restores the transformation as well. If the orienta- 
tion was correct before an attribute block, it will be again after- 
ward. 

Named coordinate systems 

We have already touched on the equivalence between geo- 
metric transformations and coordinate spaces. Each transfor- 
mation effectively defines a new set of coordinate axes that dif- 
fer from the previous set by that transformation. 

While each transformation "moves the cursor," not all of the 
coordinate spaces defined by the cursor are very interesting. 
However, there are five such spaces important enough to be 
given names. They span the rendering process from object def- 
inition to pixels. 

• "raster" is the coordinate system of the image being ren- 
dered, where (0, 0) is the top left corner of the top left pixel, 
and each pixel has a non-negative integer location. 

• "screen" is a device-independent coordinate system based 
on the image plane after perspective projection. Depend- 
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ing on its aspect ratio, the image being rendered usually 
covers approximately the square [-!,+!] in x and y of screen 
space. 

• ’’camera” space is a left-handed three-dimensional space 
with its origin at the camera viewpoint and positive 2 axis 
pointed along the direction of view. Its coordinate axes dif- 
fer from those of the world space by the current transfor- 
mation as it exists when RiWorldBeginO is called. 

• "world” space is defined as the coordinate system in effect 
immediately after RiWorldBeginO. It is the "root" coordi- 
nate system of the geometric transformation hierarchy. 

• ’’object” space for any particular object is the coordinate 
space prevailing when the object is declared. 

Only the last space differs for each object in a scene. Since 
"object” space differs for each object, RenderMan has a facility 
for giving a coordinate space a name for later reference. 


RiCoordinateSystem( space ) 

RtToken space; 

RiCoordinateSystemO marks the current coordinate system 
with a name, given by the token space, that can be referred to 
later. It is an error to mark two coordinate systems with the 
same name. 


When an object is declared, its geometric coordinates are inter- 
preted relative to the current ("object”) coordinate space, as 
given by the current transformation from object space to 
world space. That is, the current transformation is always ap- 
plied to an object. Therefore, if object geometry is supposed to 
exist in some other space, the geometry must be transformed 
into the current space before using it. 


RtPoint *RiTransformPoints(fromspace, tospace, npoints, points) 
RtToken fromspace, tospace; 

Rtlnt npoints; 

RtPoint points!]; 
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± RiTransformPointsO converts a set of points defined in the 

space named fromspace into the space named tospace. Either 
space may be one of the standard named coordinate systems 
("object”, “world", "camera”, "screen", or “raster”), or it may have 
been previously marked using RiCoordinateSystemO. points is 
an array of points to be transformed and npoints is its size. 

RiTransformPointsO cannot be expected to work correctly if the 
transformation represented by tospace is not invertible, i.e., if 
it includes deformations, or if non-invertible matrices are sup- 
plied to RiTransformO or RiConcatTransform(). 


RiTransformPointsO is useful for providing a common coordi- 
nate system to the individual primitives of an object. Since 
the current transformation is used both for assembling objects 
and arranging the scene, there is no intrinsic information 
about the "object 11 coordinate system of a composite as a 
whole. By marking the appropriate coordinate system, and 
then transforming object points from a lower level of the hier- 
archy into that system, the application can provide a common 
reference to each primitive. This is most useful for providing 
consistent parameters to shaders. 

Bounding box 

The last topic under the geometric environment concerns the 
size of objects. Many image synthesis programs use the spatial 
extent of objects or collections of objects to more efficiently de- 
termine their visibility or fix the order in which they are pro- 
cessed. This spatial extent is usually given in the form of a 
bounding box, a rectilinear box in 3-dimensional space de- 
fined by its maxima and minima in x , y and z. The bounding 
box includes every point in space between xmin and xmax in 
x , etc. (see Figure 7.5). 

The bounding box of almost all geometric primitives support- 
ed by the RenderMan interface can be easily calculated, so 
most Tenderers can and will calculate it as objects are passed 
across the interface. Bounding boxes may be supplied by the 
application in order to save calculations, or to give Tenderers 
help in situations where the bounding box is difficult to calcu- 
late, as in procedural models or CSG volumes. 



124 


Chapter 7: Geometric Transformations and Hierarchical Modeling 





bounding box 


xmin xmax 


Figure 7.5 A bounding box described by minimum and maximum x. y and z co- 
ordinates 


RiBound{ bound ) 

RtBound bound; 

The routine RiBoundO promises that all subsequent primi- 
tives will lie within the bounding box bound hound is an ar- 
ray of six RtFloat alues f^min *max }/imn Vmax z mm -max^ 

The bounding box is expressed in object coordinates in the cur- 
rent coordinate system. 

Since it is an attribute, the bounding box remains in effect for 
the duration of the current environment (i.e., until it is re- 
placed with RiAttributeEndQ). 


Note that the RtBound data is not two points, but a series of 
three pairs, each giving a bound on one axis. 

Constructive Solid Geometry 

The technique of Constructive Solid Geometry (CSG) allows 
an object to be defined as a Boolean combination of other ob- 
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jects. For example, machined parts commonly have signifi- 
cant concavities after tools remove material. A drilling opera- 
tion on an object may be modeled as the subtraction of a cylin- 
der from that object. Depicting the resulting surface any other 
way could well be prohibitively difficult. 

A solid is defined as a set of points in three-dimensional 
space, with a surface separating points in the set from those 
not in the set. Given a number of solid objects (sets of points) 
in space, one can either combine them into composite objects 
(using the set operation union), use only those points they 
have in common (set intersection) or use one solid to "carve 
out" another by subtraction (set difference). 

Since the results of these set operations can be used in further 
set operations, CSG is also a hierarchical definition tool. 

Terms 

A solid is defined under RenderMan as a boundary represen- 
tation, a set of surfaces that enclose a space. The surfaces must 
join together to completely enclose the space, providing a 
well-defined inside and outside such that roery point in space is 
either inside or outside the solid. The points of the solid are not 
necessarily contiguous (two spheres may be considered a sin- 
gle solid even without overlapping), but dire consequences 
and bizarre results can occur if there is any w T ay to get inside a 
"solid" without passing through some surface. RenderMan as- 
sumes that any object declared as a solid is sealed. 

The inside of the solid is defined as the set of all regions with 
finite volume, and the outside is the sole region with infinite 
volume. Note that this definition is independent of the orien- 
tation of the surfaces making up the object. 

A primitive solid is created as an assemblage of the primitive 
surface types discussed in Chapters 4, 5 and 6. Composite sol- 
ids are formed from primitive solids and other composite sol- 
ids in the usual hierarchical fashion. 


RiSo!idBegin( type ) 
RtToken type; 
RiSoIidEnd( ) 
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All CSG solids, whether primitive or composite, are declared 
by enclosing a series of RenderMan routines between calls to 
RiSolidBeginO and RiSolidEndO. type is a token for the opera- 
tion to be performed on the objects declared between the two 
calls. If type is RLPRIMITIVE, the intervening RenderMan sur- 
face primitives are taken to define a CSG solid. If type is 
RLUNION, RLDIFFERENCE or R1JNTERSECTION, RiSoIidBe- 
gin()/RiSo!idEnd() blocks are the only object declarations al- 
lowed. 


RiSolidBegin( RLPRIMITIVE ) 

type “primitive" (RLPRIMITIVE) forms a solid CSG object from a 
set of surface primitives. Between calls to RiSoIidBe- 
gin(RI_PRIMIT!VE) and RiSolidEndO, any set of geometric primi- 
tives may be declared. The primitives must join to completely 
enclose a volume of space. 

Listing 7.1 shows how a solid is defined. In preceding chapters 
we have defined several versions of SurfORQ for generating 
surfaces of revolution. In SolidSurfORQ, one of these objects is 
made into a primitive solid by using disks to make sure the 
two ends are closed. 


/* SolidSurtORO: create a solid surface of revolution from a set of points */ 
SolidSurfOR(points, npoints) 

Point2D points!); 
int npoints; 

I 

RiSolidBegin( RLPRIMITIVE ); 

SurtOR( points, npoints ); /* ... from Chapter 4 V 

if(points(0].y != 0.0) /* Seal the object at the ends “/ 

RiDisk( points(0].x, points(0].y, 360.0, RL^ULL i; 

if{points[npoints-1).y != 0.0) 

RiDisk( points[npoints-1].x, 

points[npoints-1 ).y, 360.0, RI_NULL ); 


RiSolidEndO; 


Listing 7.1 Using hyperboloids to create a solid surface of revolution 
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CSG composites 

Composite solids are also declared by a block of routines de- 
limited by RiSolidBeginO and RiSolidEndO. An object going in- 
to a composite may be either a primitive solid or another CSG 
composite solid. 

RiSolidBegin( ^INTERSECTION ) 

The intersection of a set of solids is defined as the set of points 
that lie inside all of them. 

One use for solid intersection is in closing partial quadrics. 
For example, a sphere formed with thetamax not equal to 360 
or 180 would have a wedge shape when solidified. It is impos- 
sible in general to close this surface exactly using the straight 
edges of a polygon. The intersection operation, however, does 
so elegantly. Listing 7.2 shows how; Figure 7.6 shows the re- 
sult. 


/* SolidWedge(radius, zmin, zmax, thetamax); make a solid from a (partial) 
w sphere as the intersection or union of two hemispheres. 

V 

SolidWedge( radius, zmin, zmax, thetamax ) 
float radius, zmin, zmax, thetamax; 

i 

if (thetamax == 1 80.0) I 

SolidHemisphere( radius, zmin, zmax ); 

I else if (thetamax == 360.0) I 

SoiidSphere( radius, zmin, zmax ); 

) else if (thetamax < 1 80.0) ( 

RiSolidBegin{ RIJ INTERSECTION ); 

SolidHemisphere( radius, zmin, zmax ); 

RiRotate( thetamax-1 80.0, 0.0, 0.0, 1 .0 ); 

SolidHemisphere( radius, zmin, zmax ); 

RiSolidEndO; 

j else if (thetamax < 360.0) | 

RiSolidBegin( REUNION ); 

SolidHemisphere( radius, zmin, zmax ); 

RiRotate{ thetamax, 0.0, 0.0, 1 .0 ); 

SolidHemisphere( radius, zmin, zmax ); 

RiSolidEndO; 



/* SolidHemisphere: create a solid hemisphere from a sphere and a cylinder*/ 
SolidHemisphere( radius, zmin, zmax ) 
float radius, zmin, zmax; 
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{ 

RiSolidBegin{ RIJNTERSECTION ); 

5o!idSphere( radius, zmin, zmax ); 

A 

' A cylinder is defined with the same radius as the sphere and 
* rotated so that its bottom bisects the sphere in the x'z Diane. 
V 

RiRotate( 90.0, 1 .0, 0.0, 0.0 ); 

A Rotate the cylinder 90 degrees in x */ 

SolidCylinder( radius, 0.0, radius ); 

RiSo!idEnd( ); A intersection V 

) 


A SolidSphere: create a closed sphere V 
SolidSphere( radius, zmin, zmax ) 

RtFloat radius, zmin, zmax; 

1 

RiSolidBegin( RLPR1MIT1VE ); 

RiSpherei radius, zmin, zmax, 360.0, RI_NULL }; 

if(fabs(zmax) < radius) A The top is chopped off 

RiDisk(zmax, sqrt(radius*radius - zmax'zmax), 360.0, RLNULL}; 

if(fabs(zmin) < radius) A The bottom is chcoped off 

RiDiskizmin, sqrt(radius*radius - zmin'zmin), 36C.0 RLNULL): 

RiSolidEndO; 

I 


A 

* SoiidCyiinderO makes a solid cylinder of the given radius, extending 

* from zmin to zmax along the z axis. 

V 

SoiidCylinder( radius, zmin, zmax ) 
float radius, zmin, zmax; 

( 

RiSolidBegin( RI_PRJM!TIVE ); 

RiCyIinder( radius, zmin, zmax, 360.0, RLNULL ); 

RiDisk( zmax , radius, 360.0, RI_NULL ); A Close the top */ 

RiDisk{ zmin, radius, 360.0, Ri_NULL ); A Close die bottom m / 

RiSolidEnd( ); 

1 

Listing 7.2 Generating solid, partial spheres and cylinders 
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The SolidWedgeQ function above uses a second CSG combina- 
tion operator, RI_UNION, which joins two other CSG solids. 

RiSolidBegin( RI_UNION ) 

The CSG "union" (RI_UNION) operator forms a solid from a 
number of other solids. The solid resulting from an RiSoiidBe- 
gin(RI_UNION) block includes all the CSG solids therein. 

At the scene level the Ri_UNION operation might seem re- 
dundant since it is equivalent to simply declaring a series of 
objects individually. Within a CSG hierarchy, however, it is 
sometimes necessary to explicitly gather a set of objects togeth- 
er to treat them as a single object. To subtract one solid from 
several other solids, for example, is easier if the latter are gath- 
ered into a single composite under the RI_UNION operator. 
The next example, in Listing 7.3, will demonstrate. 

RiSolidBegin( RI.DIFFERENCE ) 

The "difference" (RI_DIFFERENCE) operation subtracts CSG sol- 
ids from one another. After RiSolidBeginf RI_DIFFERENCE ), 
there should be a series of solid blocks. The first solid is a 
"basis" solid, and any subsequent solids within the RI_DIF- 
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FERENCE block are carved out of the initial solid. Listing 7.3 
shows the creation of such a difference solid, a bowling ball 
made by subtracting the union of three plugs from a solid 
sphere. On the left of Figure 7.7, the plugs are rendered out- 
side the ball, and the right shows the result of Listing 7.3. 


BowlingBallO 

I 

static RtColor plugcolor = ( 0.1, 0.1, 0.1 }; 

RiSolidBegin( RIJD1FFERENCE ); 

RiSoIidBegin( RI.PRIMiTIVE ); 

RiSphere' 0.3, -0.3, 0.3, 360.0, RI_NULL ); 
RiSolidEndO; 

RiSolidBegin( RHJNION ); 

RiColor( plugcolor ); 

RiRotate( 170.0, 1.0, 0.0, 0.0 >; 
BowlingBailPlugO; 

RiRotate! 30.0, 0.0, 1.0, 0.0 ); 
BowlingBailPlugO; 

Ri Rotate! 30.0, 1 .0, 0.0, 0.0 ); 
BowlingBailPlugO; 

RiSolidEndO; 

RiSolidEndO; 

I 

BowlingBailPlugO 

( 

RiSolidBegin( RI_UNION ); 

SolidCylinder( 0.03, -0.3, -0.15 ),* 

RiTranslate( 0.0, 0.0, -0.315 ); 

SolidCone( 0.075, 0.045 ); 

RiSolidEndO; 

I 

SolidCone( height, radius ) 

RtFloat height, radius; 

I 

RiSolidBegin( RI_PR1MITIVE ); 

RiConet height, radius, 360.0, RI_NULL ); 
RiDisk( 0.0, radius, 360.0, RI_NULL ); 
RiSolidEndO; 

I 

Listing 7.3 Routine for generating a bowling ball 
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Figure 7.7 The boirling ball: (left) exploded, (right) as in BowlingBalK) 


Subtraction 

The right of Figure 7.7 shows what happens to parts of the 
plugs that are not inside the sphere: they are invisible. It is 
perfectly legal for parts of a subtractor solid to lie outside the 
basis. Surfaces of the subtractor appear only if they are inside 
the basis solid. If the two solids don't intersect at all, the sub- 
tractor has no effect on the picture whatsoever. 

Shading 

In Listing 7.3, the plugs are assigned a color different from 
that of the sphere. It may seem peculiar to assign a color to a 
negative solid, but Figure 7.7 shows the result: the boundary 
surface between the two solids is colored by the subtractor sol- 
id. This may seem counterintuitive, but it actually adds some 
extra control over appearance: the subtractor solid can always 
be given the same surface characteristics as the basis if desired. 

The surface appearance of a composite solid is always well de- 
fined, because every point on the surface of a composite is on 
the surface of one of the primitives making it up. The appear- 


132 


Chapter 7: Geometric Transformations and Hierarchical Modeling 


ance of the composite is the appearance of the underlying 
primitive. 

Object Instancing 

The last hierarchical tool of the RenderMan Interface was in- 
troduced in Chapter 2 and needs little elaboration here: the 
ability to predefine models and subsequently create instances 
of them. 

Retained models 

Since RenderMan completely discards its scene data each time 
an image is rendered, it is easy to spend a lot of effort in ani- 
mation redeclaring complex objects or parts of objects that 
change little, if at all, from one frame to the next. The same is 
true of a single image that depicts a number of identical in- 
stances of one part or object. 

Defining a retained model 

RenderMan allows such repetitive data to be gathered into a 
single aggregate and copied with one procedure call. 


RtObjectHandle RiObjectBegin( ) 

RiObjectEnd( ) 

A block of RenderMan surface declaration calls bounded by 
calls to RiObjectBeginO and RiObjectEndO define a retained 
model. The model is thereafter referred to by the object han- 
dle returned by RiObjectBeginO. The object is destroyed and its 
data handle invalidated at the end of the nearest enclosing 
frame or world block. An object created before RiFrameBeginO 
will be valid for all frames, while one created within a frame 
block will only be valid for that frame, and similarly for Ri- 
WorldBegin()/RiWorldEnd(). 

Between these two calls, only procedures that declare object ge- 
ometry can be called. No transformation procedures are al- 
lowed; all surfaces are described in the same object coordinate 
system. Furthermore, only surfaces of the same type may be in- 
cluded in one retained model. 

The current transformation is not applied to the surfaces of 
the model when it is created. Rather, the model is defined in 
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exactly the coordinates supplied to the primitive routines. 
Those coordinates are transformed by the current transforma- 
tion in effect when the object is instanced. In fact, it is often a 
good idea to define a retained model outside the RiWorldBe- 
gin()/RiWorldEnd() block, so that it can be used in a series of 
frames. 


jiji RiObjectlnstance( handle ) 

RtObjectHandle handle; 

An instance of the model is created in the current space by 
calling RiObjectlnstanceO, passing it the model's handle. This 
includes in the scene any primitives in the model exactly as 
they were defined previously. The current transformation is 
applied to the surface geometry when the object is instanced, 
not when it is defined. The same is true of the rest of the 
a { graphics environment: all attributes are assigned during instanc- 

1! j ing, not during definition. 


i*« »« 

v \ r 

Listing 7.4 shows a routine, PlacePinsQ, which uses object in- 
stancing to set up the bowling pins of a bowling alley. This 
one defines a retained bowling pin using an apocryphal rou- 
tine BowlingPinQ, then instances it ten times with suitable 
; translations. 

)• 

After the model is opened by calling RiObjectBeginO, the han- 
f ' die it returns is tested. If the model couldn't be created, that 

; handle is NULL and we must abort. In that case, there is no 

need to match the failed call to RiObjectBeginO with one to Ri- 
ObjectEndO. 

The pins are set by rows; each row is diagonally offset from 
the previous one. The Nth row (beginning with 0) gets N+l 
pins. The separation between rows and between pins in a row 
is given by the procedure parameters xseparation and ysepara- 
• tion. 

There is some redundancy here. The pins in a row could be 
moved incrementally by yseparation each time, without sav- 
ing and restoring the transformation state each time through 
the inner loop. Also, the translation in each loop is 0 the first 
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time through the loop. However, these ''features'' are left in 
because they make each loop independent and make the in- 
tention of the translations somev/hat clearer. 


/* 

m PI ace Pi ns: set up ten bowling pins using object instancing. We assume 

* that the pin is centered on the z axis, and separate the rows by 

* xseparation. 

V 

P!acePins( xseparation, yseparation ) 

RtFloat xseparation, yseparation; 

I 

int row, pin; 

RtObjectHandle phandle; 
phandle = RiObjectBeginO; 

if(!phandie) /* If can't create a retained model “/ 

return; 

BowlingPini); 

RiObjectEndO; 

for( row =s 0; row < 4; row++) ( Z 9 For four rows '/ 

RiTransformBeginO; /* Independent movement for each row m / 
RiTransiate( row*xseparation, row*yseparation/2, 0.0 ; ; 
for( pin = 0; pin <= row; pin++) | /* f ipins == row*- 7 */ 

RiTranstormBeginO; 

RiTransiate( 0.0, -pin * yseparation, 0.0 ); 
RiObjectInstance( phandle ); 

RiTranstormEndO; 

1 

RiTranstormEndO; 

I 

} 


Listing 7.4 Setting up bowling pins in the x,y plane using object instancing 


The PlacePinsO routine blithely calls BowlingPinQ, but there is 
a critical assumption disguised here: BowlingPinQ must de- 
clare only one kind of primitive, and any other RenderMan 
commands are ignored, especially transformation commands. 
There could be at least three possible versions of BowlingPinQ , 
employing either polygons, hyperboloids or parametric surfac- 
es. All could be constructed without transformations, and so 
obey this stricture. But the point is worth emphasizing: re- 
tained models can include only one kind of surface. 
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Semantics of instancing 

The most important fact this example shows is that the model 
given by an object handle consists only of geometry. That is, 
the instance of the model is made by copying the geometric da- 
ta appearing between RiObjectBeginO and RiObjectEndO, ig- 
noring the graphics environment. 

This has two important consequences: first, any characteristics 
of the object that are taken from the environment (for in- 
stance, its color or the set of light sources that apply to it) are 
set when the object is instanced, not when it is declared. This 
makes it possible to color different instances differently. On 
the other hand, it also means that every part of the model receives 
exactly the same characteristics, those prevailing when RiObject- 
lnstanceO is called. 

Uses of retained models 

The main reason for using a retained model rather than re- 
peated object declarations is efficiency'. A renderer can poten- 
tially represent a retained model much more compactly, and 
perform a certain amount of processing only' once rather than 
many times. Actual savings naturally depend on the imple- 
mentation. 

Perhaps an equally important aspect of retained models is 
their use as a conceptual tool. The ability to invoke an entire 
model with a simple handle, rather than requiring a long se- 
ries of modeling commands, makes it easier to manipulate 
and use that model. 

The usefulness of retained models is limited, however, by a 
lack of control over the internal environment of the object. 
Each instance is created as though by a series of primitive dec- 
larations. All environment modifications, including specifica- 
tions of color and shading, are surrendered to the environ- 
ment as it exists when the object is instanced. 
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CHAPTER 8 

Viewing I: 
The Digital Camera 


r The discussion in this book sc far has centered on ge- 
* ometry: how to create surfaces and assemble them in- 
to a coherent scene. We now address how to render 
that scene into a digital image. As always, there are Render- 
Man routines which set various options controlling the ren- 
dering process. Since there are many such options, the render- 
ing specification can become quite involved. However, all op- 
tions have sensible defaults, so in most cases a simple 
specification suffices. 

There are three major concerns in going from a three-dimen- 
sional scene to a two-dimensional digital image. First, the con- 
tent of the image is determined by a virtual camera which 
projects the scene into two dimensions. The two-dimensional 
area which goes into the rendered image is the screen win- 
dow, analogous to the standard photographic film frame. 

After determining the content of the image via the camera 
definition, an array of pixels must be defined to represent the 
scene in a file or on a display. The rectangle of pixels which 
represents the content of the screen window is termed the 
frame. Finally, the image is produced by deriving a digital 
(usually color) value at each pixel, which represents the part 
of the scene that projects to the neighborhood of that pixel. 

Following an example program for orientation, this chapter 
covers the specification of a screen window and frame in two 
sections. Chapter 9 provides a detailed model of the rendering 
process, covers the RenderMan controls over pixel produc- 
tion, and concludes by presenting two special effects in render- 
ing. Statements emphasized with italics are key rules in under- 
standing the image definition process. 
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An Example Viewing Program 

The generic RenderMan program in Listing 8.1 shows the ba- 
sic routines for setting up the viewing parameters of an im- 
age. We'll begin this chapter with a quick pass through this ex- 
ample, then discuss its routines in more detail. The next chap- 
ter covers some other routines that affect viewing. 

The reader with access to a RenderMan Tenderer is encour- 
aged to experiment with this program. Any of the scene de- 
scription routines of previous chapters may be called between 
RiWorldBeginO and RiWorldEndQ to set up a scene for view- 
ing. Toying with the parameters of the routines shown here is 
at least as educational as a textual discussion of their meaning. 


mainQ 

I 

RtFloat fov; 

RiBegin(RI_NULL); 

A Output image characteristics */ 

A Output to file Yt.pic" */ 

RIDIsplay( ’Tuple", RI.FILE, RI.RGBA, Ri.NULL ); 

RiFormat( 640, 480, 1 .0 ); A Image resolution */ 

RiCropWindow( 0.0, 1 .0, 0.0, 1 .0 ); A Rendered subregion V 

A Camera characteristics */ 

RiScreenWindow(-1 .33, 1 .33, -1 .0, 1 .0); 

A Window on image plane */ 


I* Nature of the projection to the image plane 7 
fov =90; 

Ri Projection { "perspective*', A Perspective view *7 

RI.FOV, (RtPointer)&fov, RIJsIULL ); 

A Camera position and orientation */ 

RiRotate( 0.0, 0.0, 0.0, 1 .0 ); A Camera roil V 

RiRotate( 0.0, 0.0, 1 .0, 0.0 ); A Camera yaw */ 

RiRotate( 0.0, 1 .0, 0.0, 0.0 ); A Camera pitch V 

RiTranslate( 0.0, 0.0, 0.0 ); A Camera position V 


A Now describe the world */ 

RiWorldBeginO; 

A <Scene is described here> */ 

RiWorldEndO; 

RiEndQ; 

) 

Listing 8.1 A boilerplate viewing program 
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Overall organization 

The routines in Listing 8.1 appear in five groups. The first 
four control aspects of viewing; only the world block deals 
with scene data. This grouping and ordering of procedure 
calls makes sense for most RenderMan programs. 

Often, some of these groups will have more routine calls than 
those shown here (the others are presented in the next chap- 
ter), and often fewer or none. In fact, every call shown here be- 
tween RiBeginO and RiWoridBeginO could be omitted because 
the values they assert are exactly the default. The set of de- 
faults for the viewing parameters is designed to be widely use- 
ful to minimize the number of routines that any given pro- 
gram needs to call. 

Image characteristics 

The first group of statements controls the physical characteris- 
tics of the output image: 

• the type and name of the device (normally either a display 
or file) to which the image will be output, and whether 
each output pixel contains color, depth and/or coverage 
information (RiDisplayO); 

• the horizontal and vertical resolution of the image, and 
the aspect ratio (width/height) of the individual pixels 
(RiFormatO); 

• what portion of the image as defined will actually be ren- 
dered (RiCropWindowO). 

Camera characteristics 

Next, the example specifies where the film frame lies on the 
image plane (RiScreenWindowO). 

Projection 

The call to RiProjectionO controls how the three-dimensional 
geometry of the scene is cast onto the two-dimensional image 
plane from which the image will be taken. This call to RiPro- 
jectionO specifies that the scene will be rendered using a per- 
spective projection with a 90° field of view. 
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Camera placement 

The last set of viewing parameters concerns the placement of 
the camera. Any geometric transformations occurring after 
RiProjectionO and before RiWorldBeginO concern the camera. 
The most important routines for camera control are RiTrans- 
Iate(), to control where it lies, and RiRotateO, to control its ori- 
entation. The fact that the routines as called here do nothing 
reflects the fact that the default camera placement is at the 
world-coordinate origin, facing along the positive z axis. In 
other words, world and camera coordinates are identical by de- 
fault 

Options vs. transforms 

One might wonder how important it is for the routines in 
Listing 8.1 to appear in this order. Each one either sets options 
(e.g., RiFormatO, RiDisplayO) or affects the viewing transforma- 
tion (RiRotateO and RiTranslateO). Basically, routines of the 
first kind are independent of the order in which they appear 
(as long as they all appear after RiBeginO and before RiWorld- 
BeginO), while the order of the transformation commands is 
critical. The reasons for this relate to the nature of geometric 
transformations and how options are assumed to be processed. 

When RiWorldBeginO is invoked, all options are frozen and 
cannot be changed until RiWorldEndO. This is primarily due 
to the RenderMan assumption that rendering may begin any 
time after scene description begins. Therefore, any image- 
wide parameters (options) must be fixed by then. However, 
there is a second issue: a number of option defaults are not 
specific values, but are derived from other options. For exam- 
ple, the default screen window, if RiScreenWindowO is not 
called, is derived from the image aspect ratio given to RiFor- 
matO or RiFrameAspectRatio(). These defaults are calculated 
during RiWorldBeginO. In that sense, options are not really 
"accepted" until then, so all non-geometric option declara- 
tions are order-independent. 

Order of transforms 

The same is not true of geometric commands for positioning 
the camera. As with the other options, RiWorldBeginO marks, 
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or accepts, the current transformation as the viewing transfor- 
mation. But the order of transformations making up the cur- 
rent transformation is just as important for viewing as it is 
for modeling. 

A Virtual Camera 

This section describes the geometric considerations for setting 
up the synthetic camera. No matter how automatic a camera 
is, someone still has to decide where to put it (that is, provide 
a viewing location) and point it (impose a viewing direction). 
In the real world, photographers also affect the resulting im- 
age by choice of camera type, lens and film. Among other 
things, these decisions influence how much of the world the 
camera sees in the direction it points (its field of view) and 
the camera's output (the film frame in conventional photog- 
raphy) as a rectangular region (the screen window) of the im- 
age plane on which the lens focuses. This information togeth- 
er defines the virtual camera for viewing a scene. 

The parameters above are not always orthogonal. For exam- 
ple, an object may be made larger in the image bv either mov- 
ing the camera closer or narrowing the lens' field of view. 
Similarly, the effect of narrowing the field of view can be du- 
plicated by making the screen window smaller. In the first 
case the image looks somewhat different for the two approach- 
es, but in the second case the results are identical. 

Partly because the physical camera model is ambiguous (in 
the sense that its parameters are not completely orthogonal), 
RenderMan does not provide a specific camera model, but a 
set of routines that can be used to construct a variety of reason- 
able camera models. This section presents one such virtual 
camera, controlled by two routines that RenderMan calls to 
describe it. These camera routines should provide some in- 
sight into the RenderMan calls that thev use. 

The viewing transformation 

In the RenderMan model, a scene is rendered from a view- 
point at the coordinate origin of camera space , looking out 
along the positive z axis. If the camera needs to be some place 
other than the world origin, or pointing in some other direc- 
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tion, then a viewing transformation must be provided to 
transform points from world space into camera coordinates. 

RenderMan allows the user to apply any geometric transfor- 
mation to the world in order to position it before the camera. 
The only difference between a geometric transformation used 
to assemble a scene and one used to build up a viewing trans- 
formation is context: any transformation routines called before Ri- 
WorldBeginO are assumed to be part of the viewing transformation. 
Any such calls made afterward are considered part of the mod- 
eling transformation. 

A simple camera procedure 

Listing 8.2 shows a useful setup procedure for a viewing trans- 
formation based on the position, direction and orientation of 
a camera. 


^include <ri.h> 

A 

* PlaceCameraQ: establish a viewpoint , viewing direction and orientation 

* for a scene. This routine must be called before RiWorldBeginQ. 
m position: a point giving the camera position 

* direction: a point giving the camera direction relative to position 

* roll: an optional rotation of the camera about its direction axis 

V 

PJaceCamera ( position, direction, roll ) 

RtPoint position, direction; 
float roll; 

1 

RildentityO; A Initialize the camera transformation */ 

RiRotate( -roll, 0.0, 0.0, 1 .0 ); 

AimZ( direction ); 

RiTranslate( -position J0J, -position!!], -position[2] ); 

I 


A 

* AimZ(): rotate the world so the d irect ion vector points in 

9 positive z by rotating about the y axis, then x . The cosine 

* of each rotation is given by components of the normalized 

* direction vector . Before the y rotation the direction vector 

* might be in negative z, but not afterward. 

V 
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#detine PI 3.14159265359 
#include <math.h> 

AimZ( direction ) 

RtPoint direction; 

i 

double xzlen, yzien, yrot, xrot; 

indirection [0]==0 && direction ( 1 ]==0 && direction[2J==0) 
return; 

/* 

m The initial rotation about the y axis is given by the projection of 
' the direction vector onto the x,z plane: the x and z components 

* of the direction. 

V 

xzien = sqrttdirection [0| ^direction [01-hdirection[2 J “direction [2J); 
if(xzlen == 0) 

yrot = (direction [1 ] < 0) ? 1 80 : 0; 
else 

yrot = 1 80"acos(direction[2]/xzlen)/PI; 

/* 

* The second rotation , about the x axis , is given by the projection on 
m the y,z plane of the y- rota ted direction vector: the original v 

* component . and the rotated x,z vector from above , 

V 

yzien = sqrt(direction[1 Indirection [ 1 ]+xzlen“xzien); 

xrot = 1 80"acos(xzIen/yzlen)/PI; /* yzien should never be 0 */ 

if( direction!!] > 0 ) 

RiRotate( xrot, 1 .0, 0.0, 0.0 ); 

else 

RiRotate(-xrot, 1 .0, 0.0, 0.0 ); 

/* The iast rotation declared gets performed first V 
i f( direction!©] > 0 } 

RiRotatei-yrot, 0.0, 1 .0, 0.0 ); 
else 

RiRotate( yrot, 0.0, 1 .0, 0.0 ); 


Listing 8.2 A simple camera specification 


Camera translation 

The initial call to RildentityO clears the viewing transforma- 
tion. Since the camera will be rotated about the viewpoint, 
the translation to make the viewpoint coincide with the coor- 
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dinate origin must be applied first. Therefore it is declared 
last. The negative camera position coordinates in RiTranslateO 
are important: the world is being translated away so as to 
move the "camera location" to the coordinate origin. 

Camera direction 

The function AimZi) points the z axis in an arbitrary direction. 
Similarly to the translation, we are really rotating the world 
so that the desired direction vector points along the z axis: any 
point that formerly lay along the direction vector from the 
viewpoint now lies on the z axis. 

Camera roll 

When taking pictures in the world, "up" on the film is usual- 
ly aligned with "up" in the world. AimZO assumes that "up" 
parallels the positive y axis. The rotation performed by RiRo- 
tateO in PlaceCameraQ provides for "head tilting" via a rota- 
tion about z controlled with the roll parameter. 

General camera transformation 

The above camera specification underscores the fact that posi- 
tioning, pointing and orienting (in short, transforming) a 
camera from the coordinate origin in world space is equiva- 
lent to applying the inverse transformation to the rest of the 
world. One can also view the camera transformation as mov- 
ing the world coordinate axes away from the camera system. 
Its inverse, then, expresses the camera relative to the world. 

Formally, if one treats the camera as an object defined at the 
coordinate origin of world space pointed along the z axis, it 
might be positioned by N geometric transforms xformiQ 
through xformiQ: 

xform N ( xform^j ( ... xform j( cam ) ...)) 

where xform] () is performed first. The RenderMan camera 
specification uses the fact that this series of transforms on the 
camera is equivalent to the following transformation applied 
to the world : 

xform. j 1 ( ... xfomf^ ( xform ^ ( world ))... ) 
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where world stands for every object in the world defined with 
geometric coordinates. 

Looking at the camera transform this way yields a very useful 
fact: if the specification of a camera in world space can be re- 
duced, as it often is in modeling systems, to a 4 x 4 transforma- 
tion matrix (call it CameraMatrix), and that matrix can be in- 
verted as CameraMatrixInverse, then 

RiTransform( CameraMatrixInverse ) 
is a complete specification of camera geometry. 

Describing the camera 

The procedures in Listing 8.2 concern the placement of a cam- 
era. The second part of a reasonable camera specification con- 
cerns characteristics of the camera itself. A synthetic camera is 
defined by how it derives a bounded image on some image 
plane from the three-dimensional world before it. The objects 
of the scene are first clipped to discard elements behind the 
camera. 

Clipping planes 

Only objects which are in front of the camera should appear 
in an image. In most renderers, this is expressed as a clipping 
plane perpendicular to the z axis in camera space and usually 
close to the camera. It is declared as a single depth (z) value. 
Any object nearer in depth is invisible. RenderMan also sup- 
ports a far clipping plane, beyond which any object is invisible. 


RiC!ipping{ near, far ) 

RtFloat near, far; 

near and far are distances from the camera, z values in camera 
space (after the camera transformation). The special value 
RI_EPSILON is slightly greater than 0, and is the minimum 
value allowed for near. RMNFINITY is the largest represent- 
able value and may be used in far to include all objects. If 
RiClippingO is not called, near and far are R1JEPSILON and 
RMNFINITY, respectively, so that almost all data in front of 
the camera is rendered. 
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i 

¥ 

_ The main reason for moving the clipping planes from their 

default is to declare bounds for a scene. Rendering is often 
more efficient if the clipping bounds are close to the actual 
bounds of the scene. 

Model of projection (a digression) 

The essential purpose of the camera is to derive a two-dimen- 
sional image from a three-dimensional scene. Whether one is 
rendering a three-dimensional digital model or snapping pic- 
tures with a camera, the basic purpose is to project a three-di- 
mensional array of illuminated objects onto a plane, and take 
a rectangular area of that plane as a two-dimensional image. 
The perspective projection typically used in computer graph- 
ics mimics a physical camera, in which light rays pass through 
a lens, converge at a focal point and focus on an image plane. 
The focal point of a RenderMan camera is the same as the 
viewpoint located at the coordinate origin. The image plane is 
one unit away in positive z (in front of the viewpoint), which 
means that the projection passes through the image plane on 
the way to the focal point. In an orthographic projection, a 
point in the scene is projected directly onto the image plane 
along a line parallel to the z axis. 

A rectangular region of the image plane is captured in the im- 
age itself. That region is called the film frame in photography 
and the screen window in RenderMan. The distance between 
the focal point and the image plane is the focal length of the 
camera. 

An important fact is that the size of the output image in pixels is 
independent of the size of the screen window. The screen window 
concerns the content of the image, while the size of the output 
image is a function of how that content is represented. Once 
again, photography provides the model: the size of an enlarge- 
ment made from a negative is independent of the negative it- 
self. 

For a given screen window and focal length, there is a pyrami- 
dal volume of space containing the parts of the scene that 
project within the screen window and thus appear in the im- 
age. The same is true of a physical camera: what actually ap- 
pears in the film frame is a clearly defined part of the world. 
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Figure 8.1 Two cameras with different fields of view 


The pyramid is characterized by the angle between opposite 
sides, termed the camera's field of view. 

If the size of the screen window is fixed, then moving the fo- 
cal point closer to the image plane widens the field of view, 
and moving it farther away narrows it. Conversely, if the fo- 
cal point is fixed (as it is with the RenderMan "camera"), then 
the field of view can be manipulated by defining a larger or 
smaller screen window. 

Figure 8.1 shows two abstract cameras with fixed focal length 
but different fields of view, as determined by varying the 
screen window. The wider screen window includes more of 
the world in the frame and generally makes objects appear 
smaller. A narrower field corresponds to a telephoto lens, 
which excludes more of the scene and enlarges farther objects. 

The fact that the focal length of the RenderMan camera is 
fixed at 1 might seem a limitation. However, the important 
thing is how the world is projected onto the image plane with- 
in the screen window. Figure 8.2 shows that the field of view 
is completely determined by the ratio of the focal length to the 
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Figure 8.2 Constant ratios of focal length and frame width give constant field of 
z new. Doubling the focal length and frame width at the same time leaves the field 
ofvieu > unchanged. 


frame width, since doubling both leaves the field of view un- 
affected. A little trigonometry indicates that 

field of view = 2 *atan[ t rame __} v idih / /. ^ 

V focal length J 

Notice that if the screen window is not square, the field of 
view will be different in the horizontal and vertical direc- 
tions. Specifically, it will be wider in the longer dimension. In 
RenderMan, the field of view is measured in the narrower of 
the two directions. 

In a physical camera, the screen window is fixed by the film 
format, and the focal length is varied by selecting a lens or by 
setting a zoom lens. Under the RenderMan Interface, the focal 
length is always 1, but both the screen window and the field of 
view can be set directly to bring more or less of the world 
within the screen window. There is interplay between the two 
parameters, since widening the screen window has the same 
effect as widening the field of view. 

Listing 8.3 shows a simple routine, FrameCameraQ, which 
takes a camera description in terms of the focal length of a 
lens and the width and height of the film. FrameCameraQ ma- 
nipulates the screen window to simulate that camera, leaving 
the field of view fixed. 
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/* Focal length of 0 is taken to be an orthographic projection V 
if( focallength != 0.0 ) [ 

RiProjection( "perspective", RI_NULL ); 
normwidth = {framewidth *.5 }/focal length; 
normheight = (frameheight* .5 )/focal length; 
else | 

RiProjection{ "orthographic", RI_NULL ); 
normwidth = framewidth ‘.5; 
normheight - frameheight*. 5; 

RiScreenWindowf -normwidth, normwidth, -normheight, normheight ); 


Listing 8.3 Camera specification in terms of a physical camera 


Perspective projection 

FrameCameraQ takes three parameters: the width of the film 
image ( framewidth ), its height ( frameheight ), and the focal 
length of the lens used ( focallength ) in a hypothetical camera. 
The units used are unimportant. It might be inches or milli- 
meters if one wants to model a film camera; it might be 
square pixels for a digital representation. But the units must 
be the same for all three parameters. 

Projection 

The first RenderMan call in Listing 8.3 is RiProjectionQ. 



RiProjection( name, parameterlist) 
char ‘name; 

RiProjectionO takes the name of a projection method for going 
from three-dimensional points onto the image plane. Two 
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standard projection methods, "perspective" and "orthographic", 
are predefined in RenderMan. The former provides a perspec- 
tive transformation that includes all objects within a 90° field 
of view. Other fields of view may be supplied using the 
RI_FOV parameter, as in the following: 

RtFloat fov; 

RiProjectionf "perspective'', RI_FOV, (RtPointer) &fov, RI_NULL); 

The RI_FOV parameter must be less than 180°. This parameter 
causes the perspective projection to also scale the world so 
that the requested field of view angle exactly fills the -1 to 1 
square on the image plane. 

An orthographic projection projects each point onto the im- 
age plane along a path parallel to the z axis, simply discarding 
the z coordinate of any point. 

The parameterlist of RiProjectionO may also be used to pass pa- 
rameters to nonstandard projections. 


Figure 8.3 illustrates the effect of varying the RI_FOV parame- 
ter from a small value at top (corresponding to a telephoto 
lens) to a large value (a fisheye lens) at bottom. The middle 
image is the default. 

Screen window 

FrameCameraQ defines the screen window according to the ra- 
tio between the frame width and the focal length (see Figure 
8.4), normalizing the "camera" to a focal length of 1. Frame- 
CameraQ takes a special focal length of 0 to indicate an infi- 
nitely long lens, necessitating an orthographic projection onto 
the image plane. Normally a perspective projection is used. 

RiScreenWindowO specifies the screen window as a bounding 
box in x and y on the image plane. 


RiScreenWindow( left, right', bottom, top ) 

RtFloat left, right, bottom, top; 

RiScreenWindowO declares a screen window, the boundaries 
of an image on the image plane. The image will consist of exactly 
the part of the scene that projects onto the image plane within the 
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Figure 8.3 Field-of-vira ; parameter of RiProjection() 


screen window . left and right are the bounds of the window in 
the negative and positive x direction, respectively, and bot- 
tom and top are its bounds in the negative and positive y di- 
rections. If left> right or bottom > top , the image will be reflect- 
ed about the appropriate axis. 

The parameters of RiScreenWindowO are defined in screen 
space, in which x is positive to the right and y is positive up- 
ward. Thus, a typical screen window is the unit square 

left: = -1 
right = +1 
bottom = -1 
top = +1 
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The default screen window is the same shape as the output 
frame, and contains the unit square on the image plane. The 
frame shape is affected by RiFormatO, RiDisplayO and 
RiFrameAspectRatioO. 


Uncentered windows 

FrameCameraQ centers the screen window about (x=0,y=0) on 
the image plane, where the viewing direction is perpendicu- 
lar to the image plane. This corresponds closely to the design 
of almost all modern cameras. However, it is quite reasonable 
to define uncentered windows. 

At large offsets, an image becomes significantly tilted with re- 
spect to the viewing direction. This property recalls view cam- 
eras, which can tilt the film plane to compensate for perspec- 
tive distortion. A picture taken from street level can make tall 
buildings appear less sharply raked if the film plane can be 
made parallel to the buildings even though the camera is 
looking up. An uncentered window could be passed to Ri- 
ScreenWindowO to achieve the same effect. 

An alternative camera 

The usual screen window is -1 to +1 in both x and y. Since 
the RenderMan focal length is fixed at 1, the perspective pro- 
jection into this window corresponds to a field of view of 90 
degrees (see Figure 8.4). This is roughly the equivalent of a 
35mm lens on a 35mm camera, slightly wider than a 
"normal" lens. The version of FrameCameraQ above simulat- 
ed a change in the field width of the lens by changing the size 
of the screen window. It might not be considered convenient 
or intuitive to control the size of the field by sizing the screen 
window; it would be like changing film formats instead of us- 
ing a zoom lens. It is actually unworkable if one wants the 
screen window to be set automatically based on the output 
frame. One must avoid calling RiScreenWindowO in that case. 
The field of view can be controlled directly by leaving the 
screen window alone and providing an RI_FOV parameter to 
RiProjectionO, which will then control what falls inside the de- 
fault screen window, rather than resizing the screen window 
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I screen window 


Figure 8.4 90° field of view with focal length of l puts screen window at 1 


itself. Specifically, fov is the angle between sides of the view- 
ing frustum enclosing objects which are projected within the 
unit square on the image plane. In other words, if it's inside 
the viewing frustum, its image space coordinates will be be- 
tween -1 and +1 on the image plane. 

The RI_FOV parameter to RiProjectionO frees us from the ge- 
ometry of the focal point, screen window and field of view, to 
give us what we really want: direct control over the field of 
view seen by a given screen window on the image plane. It de- 
termines exactly what will appear in any given screen win- 
dow. 

That makes two nearly equivalent ways to select part of the 
world along the direction of view for rendering: RiScreenWin- 
dow() and RiProjectionO. Just to make this relationship clear. 
Listing 8.4 shows an alternative version of FrameCameraO 
that uses the latter method. 

This version of FrameCameraO replaces RiScreenWindowO 
with a new routine, RiFrameAspectRatioO. It sets the default 
screen window indirectly: rather than giving specific bounds, 
it says only that the output frame, and by implication the 
screen window, should have a specific shape, specified as the 
ratio of width to height. The resulting screen window just en- 
closes the unit square on the image plane. In Listing 8.4, the 
field of view is again derived from the focal length, frame 
width and the frame height. Here, though, the minimum of 
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/* FrameCamerafl: give physical parameters for a camera. 

* Parameters: 

* focal length: controls the width of the camera's field of view . 

* framewidth: the width of the film image 

* frameheight: the height of the film image*/ 

#include <ri.h> 

#include <math.h> 

FrameCamera( focallength, framewidth, frameheight ) 
float focallength, framewidth, frameheight; 

I 

RtFloat fov; 

f* A nonzero focal length is taken to be a " normal " lens */ 
iff focallength != 0.0 ) I 

fov = 2 * atanf {min(framewidth,frameheight)*.5)/fbcallength ); 
RiProjection( “perspective' 1 , 

RLFOV, (RtPointer)&fov, RI_NULL ); 

) else 

RiProjectionf “orthographic", RLNULL ); 

RiFrameAspectRatio( (RtFloat)(framewidth/frameheight) ); 

I 


Listing 8.4 Alternative camera description using RiPerspectiveO to control the 
field of view 


the width and height is used to calculate the field of view be- 
cause the minimum dimension maps to the unit square. 

This completes the discussion of RenderMan's controls for de- 
termining what part of the three-dimensional world will ap- 
pear in the output image. We can now turn to the question of 
how that information is represented in the image. 

The Digital Image 

The camera procedures PlaceCameraQ and FrameCameraQ are 
as valid in an analog world as in a digital one because they 
concern a continuous image within the screen window on 
the image plane. The next part of the viewing process con- 
cerns how the visual information within that window is rep- 
resented as a digital image with specific vertical and horizon- 
tal pixel resolution. 

Display description 

First, the destination of the image must be specified, whether 
it is to be displayed on a frame buffer or stored in an image 
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file. At the same time, the nature of the information recorded 
at each pixel is detailed. 


RiDisplay( name, type, mode, parameterlist ) 
char ’name; 

RtToken type, mode; 

RiDisplayO declares the destination of the image being ren- 
dered. type determines the device type, e.g., "file" (RI_F!LE) or 
"framebuffer" (RI_FRAMEBUFFER). name gives a specific display 
device name or the name of the output file, mode is a string 
specifying the information to be stored at each pixel. It con- 
tains combinations of "rgb", "a" and "z", for full color, coverage, 
and depth information, respectively. 

By default, the upper left pixel of the image — (0,0) in screen 
space — is placed at the upper left pixel of the file or display. 
The "origin" (RI_ORIGIN) parameter of parameterlist may be 
used to change this. Its value is an array of two Rtlnt values 
giving a horizontal and vertical offset for the image relative 
to the display or file. If the image goes to a file, the origin is 
stored in the file for possible later use in displaying it. If the 
image is being rendered to a display, a positive origin displac- 
es the upper left pixel of the image to the right and down 
from the top left pixel of the display. The origin does not affect 
the content of the image as rendered; it will contain exactly 
the same portion of the scene no matter what the origin. The 
origin affects only the physical destination of the pixels. 

The parameterlist of RiDisplayO may also be used to pass any 
device- or implementation-dependent display parameters. 


Display type and name 

type, which concerns the physical destination, is usually ei- 
ther RI_FRAMEBUFFER or RI_FILE. If the image is to be stored 
in a file, then name gives the file's name. The meaning of 
name for frame buffers depends on the nature of the frame 
buffer and its interface to the Tenderer. This is an especially 
implementation-dependent parameter in the RenderMan In- 
terface; it is meant to signify a device name, whether on a dis- 
play or on external storage. 
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Image resolution 


RiDisplayO determines the physical destination of the image 
data. The other key attributes of the output are its resolution 
(numbers of rows and columns of pixels) and the aspect ratio 
of individual pixels. The pixel aspect ratio is simply 

ar - 

P pixelheight 

where the pixelwidth and pixelheight are the horizontal and 
vertical size of each pixel on the display. 


Display mode 

mode indicates the type of information that should be stored 
at each pixel. For simple display, the pixel s color is usually 
sufficient. The mode string "rgb" (R1_RGB) indicates that color 
values should be stored. Some Tenderers can be used to extract 
other information from scenes. For example, it is often useful 
to retain coverage information indicating the extent to which 
a pixel was formed from objects in the scene as opposed to the 
background. Historically known as alpha, this information 
can be stored with the pixels of an image by including "a" m 
the mode String. The distance of the surface nearest the view- 
ing plane at a pixel may be recorded by including z m the 
mode string. 

mode may include combinations of the above strings. By con- 
vention, they should appear in the order "rgb", "a" and "z". For 
example, if mode is "rgba" then both color and coverage infor- 
mation are stored in the pixels. A mode of "az" stores coverage 
and depth, "rgbaz" stores all the above information, and could 
be used to composite a number of images that depict different 
objects in the same scene [DUFF85]. 


RiFormatO sets the horizontal and vertical resolution of an 
image, and declares the aspect ratio (width/height) of its pix- 
els. pixeiaspecirailo may be negative to indicate that the de- 
fault of the display as specified by RiDisplayO should be used. 
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Rtlnt xresolution, yresolution; 

RtFloat pixeiaspectratio; 
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When an image is rendered to a file, xresolution and yresolu- 
tion specify the horizontal and vertical resolution of that file. 
When the image is being rendered to a display device with Ri- 
DisplayO, presumably the device has a physical pixel aspect ra- 
tio. RiFormatO can defer to that value by giving a negative pix- 
elaspectratio. xresolution and yresolution, together with any 
"origin" parameter provided to RiDisplayO, define a rectangu- 
lar region of pixels to be rendered onto the display. If this im- 
age does not fit on the display (either because it is too big or be- 
cause the origin given to RiDisplayO causes the raster to over- 
lap the display bounds), any pixels that cannot be displayed 
are cropped. That is, a given pixel within an image will be assigned 
exactly the same portion of the scene independent of the capabilities 
of the display. This is in contrast to shrinking the image to fit it 
into the display, which would inevitably change the relation- 
ship between pixels and the scene. 


Figure 8.5 shows the relationship between the origin given to 
RiDisplayO, the resolution of the image and that of a display. 
The pixels at the top and left of the display are left untouched, 
while those outside the display bounds at the right and bot- 
tom are cropped. 


Relationship between screen window and image 

We can now predict what portions of the scene appear in the 
image (namely the screen window) and the size of the output 
image. The single remaining issue is the relationship between 
the two. 


The pixel aspect ratio supplies an important piece of informa- 
tion: together with the horizontal and vertical resolutions, it 
determines the image aspect ratio, its physical shape when 
displayed. 

The aspect ratio of an image is given by the ratio of its physi- 
cal .width and height. If res} , and res v are the horizontal and 
vertical resolution of the display, then the aspect ratio of the 
image is 


flr= a V res h 

i 


res,. 
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If pixels are square, then the image aspect ratio is simply the 
ratio between the horizontal and vertical resolution as mea- 
sured in pixels. 

The image aspect ratio is important for one reason: the project- 
ed contents of the screen window map directly to the pixels of the im- 
age. If the image aspect ratio does not match that of the screen win- 
dow, the image will appear distorted. RenderMan normally 
avoids distortion by using a screen window which matches 
the image aspect ratio. If no screen window is specified (Ri- 
ScreenWindowO is never called), then RenderMan defines a 
screen window with the same shape as the image and the out- 
put is undistorted. 

If a screen window is defined by the application, and it fails to 
match the shape of the image, distortion normally results. 
However, sometimes a particular output aspect ratio is de- 
sired, regardless of the display used. FrameCameraQ was an ex- 
ample of that: we wanted an output in the shape of a physical 
film frame. In the second version of FrameCameraQ, RiFrame- 
AspectRatioO did exactly that. 

How is this desired frame reconciled with the shape of the im- 
age defined by RiDisplayO and RiFormatO? Simple: if the shape 
of the frame given by RiFrameAspectRatioO does not match that 
of the output image, then pixels are left untouched at either the 
right or the bottom of the image. 
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RiFrameAspectRatiol frameratio ) 

RtFloat frameratio; 

RiFrameAspectRatioO decrees that the picture contained in the 
output image will have width/height = frameratio regardless 
of the display or file being generated. If this frame aspect ratio 
differs from that of the output image as a whole, then pixels 
will be untouched at either the right or the bottom. 

If RiScreenWindowO is never called, RiFrameAspectRatioO also 
determines the screen window. The default screen window al- 
ways just fits the square from -1 to +1 in x and y into the dis- 
play. Therefore, if frameratio > 1 (the frame is "horizontal"), 
the default screen window is - frameratio to +frameratio in x 
and -1 to +1 in y. If frameratio < 1 , it will be -1 to +1 in x and 
— 1 /frameratio to +Vt'rameratio in y. If both RiFrameAspectRa- 
tioO and RiScreenWindowO are called, and the screen window 
does not match frameratio, then the output image will be dis- 
torted. 


Image vs. frame 

Since the pixels in the output image may not all be rendered, 
we now have the motivation for a bit of new nomenclature. 
We will use the word image to refer to the array of pixels de- 
fined by RiDisplayO and RiFormatO, all of which are rendered 
in the absence of a call to RiFrameAspectRatioO. The frame is 
the subset of the image stipulated by RiFrameAspectRatioO. It 
has two important roles. 

First, the frame limits the set of pixels in the image that are ac- 
tually rendered. The image and the frame may differ only in 
their aspect ratios; pixels may be untouched at either the right 
or the bottom of the image, but not both. If RiFrameAspectRa- 
tioO is never called, the frame and the image are the same. 

Second, the pixels within the frame form a digital rendition 
of the contents of the screen window. The screen window is al- 
ways mapped to the frame, not the image. Therefore, the impor- 
tant issue in avoiding distortion is to match the aspect ratios 
of the screen window and the frame. 
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This relationship between the frame and the screen window 
completely specifies the relationship between data in the 
scene and pixels in the image. It does not imply that all the pix- 
els of the frame are actually rendered. If part of the frame lies 
outside a display, that part is simply not rendered; the remain- 
ing pixels will receive exactly the same information that they 
would if the image were complete. 

The following few paragraphs give examples of how to meet 
some common formatting needs. 

Filling the display 

If the user wants only to fill the display with the scene, then 
only one line is required. Assuming that the name of the dis- 
play is "mydisplay”, that line is as follows: 

Ri D ispiay (“m y d i s p I a y 1 ', RI.FRAMEBUFFER, RI_RGB, RI_NULl); 

The screen window will be defined to match the shape of the 
display (just enclosing the -1 to +1 range on the image plane), 
and the frame will be defined to encompass every pixel in the 
display. 

Creating an image file 

Since a RenderMan Tenderer produces a file by default, if the 
user wants to create an image file 700 pixels wide and 500 pix- 
els high, then only the call 

RiFormatl 700, 500, 1 .0 ); 

is needed. If the file should be called "myfile" instead of 
"ri.pic"(the default), then the sequence 

RiDisplayCrnyfile 1 ', RI_FILE, RI_RGB, RI_NULL); 

Ri Format! 700, 500, 1 .0 ); 

would be used instead. Finally, if the file will be used on a dis- 
play with pixel aspect ratio 0.9, the only way for RenderMan 
to know that would be with the call 

RiFormat( 700, 500, 0.9 ); 

Windowing onto a display 

To render into a window on a display device, one need only 
specify the size and origin of the window, the former to RiFor- 
mat(), the latter to RiDispIayQ. If one wanted to render a 
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512 x 384 window on "mydisplay", offset by 128 pixels in x and 
200 pixels in y, then the following fragment would apply: 

Rtlnt origin(2); 

originfO] = 128; 
origin(l) = 200; 

RiDtsplayC'mydisplay", RI_FRAMEBUFFER, RI_RCB, 

“origin", (RtPointer) origin, R!_NULL); 

RiFormaK 512, 384, -1.0 ); 

This specification is designed to be independent of the particu- 
lar display device used. Since the pixel aspect ratio passed to 
RiFormatO is -1.0, that of the display is used. If the display 
doesn't have enough resolution to display the window, then 
only the part of it that does fit will be seen. 

Enforced frame aspect ratio 

The handiest use of an enforced aspect ratio is in specifying 
the shape of the output independent of the display. The reso- 
lution and aspect ratio of a display are implicit in the RiDis- 
playO command that sets it up. If an image should be ren- 
dered onto display "mydisplay" with aspect ratio 4:3, the se- 
quence 

RiDisplayC'mydisplay", RI_FRAMEBUFFER, RI_RGB, RI_NULU; 
RiFrameAspectRatio( 4.0/3. 0 ); 

takes care of everything: the screen window will be -4.0/3. 0 to 
+4.0/3.0 in x and -1 to +1 in y, and the image will be as large 
as can fit on the display without distortion. 

If output is to a file, there is little point in defining the file to 
be of a different shape than the frame. For example, the call 

RiFormatf 1024, 768, 1 .0 ); 

would provide a 1024 x 768 image with square pixels, which 
would have exactly the same shape. So would a file with 

RiFormat{ 1024, 1024, 4.0/3.0 ); 


Use of image distortion 

You may want a distorted image. Anamorphic wide-screen 
movie formats (Panavision, for example) laterally compress a 
wide field into a conventional 35mm frame and reverse the 
process optically during projection. 
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Dedaring a screen window with a different aspect ratio than 
the image is an easy way to achieve this effect. Suppose a 
screen window^ with an aspect ratio of 2:1 is to fit within a 
frame of aspect ratio 4:3. Then the sequence 

RiFrameAspectRatiof 4.0/3 .0 ); 

RiScreenWindow( -2, 2, -1 , 1 ); 

will do the job no matter what the characteristics of the dis- 
play or output file. So will the sequence 

RiFormat( 512, 364, 1 .0 ); 

RiScreenWindow) -2, 2, -1 , 1 ); 

RenderMan will fill the entire 512 x 384 image. The physical 
output will therefore have aspect ratio 4:3. 

Rendering a subwindow 

Sometimes a user wishes to render only a part of the frame, 
or to render it in tiles and assemble them later. 


RiCrop Window) left, right, top, bottom ) 

RtFloat left, right, top, bottom; 

left, right, top and bottom are floating-point values between 0 
and 1 such that left < right and top < bottom (they are swapped 
to suit if they are not passed that way). They define a rectangu- 
lar subregion, the crop window, of the output frame (not the 
image); the call 

RiCropWindow) 0.0, 1 .0, 0.0, 1 .0 ) 
renders the entire frame, which is the default. 

The values passed to RiCropWindowO are expressed in screen 
space, in which x increases positively to the right and y in- 
creases positively downward: the screen window [.75 1 0 .25] 
describes the upper right sixteenth of a frame. 


RenderMan does not render fractional pixels. The window de- 
fined by left, right, top and bottom is taken to integer pixel loca- 
tions. Specifically, if pixels in the frame run from 0 to fares- 1) 
horizontally and 0 to (yres— 1) vertically, then the window actu- 
ally rendered is 
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rxmin = rieft*xres] 
rxmax = [(right+xresMl 
rymin = |"top *yres\ 
rymax = Rbottom^yres)— ll 

Under this definition, if left= right or bottom=top no pixels are 
rendered. That can even be true when left is slightly less than 
right . However, this definidon of the rendered pixels does 
have the property of perfect tiling. One can divide the [0,1] 
square into a set of panels and render them separately. As 
long the panels do not overlap in the floating-point parame- 
ters to RiCropWindowO, no pixel will be rendered twice, and 
as long as the square is covered completely, every pixel will be 
rendered in one of the panels. 

A final example 

Figure 8.6 illustrates the pixels rendered by the following spec- 
ification: 

RiForma t( 1280, 1024, 1.0 }; 

RiFrameAspectRatio< 1 .0 ); 

RiCropWindow( .125, .75, .125, .5 ); 

RiDisplay( "mydisplay 1 ', RI_FRAMEBUFFER, RI_RCB, RI_NULL ); 

A large horizontal image with square pixels is defined by Ri- 
Format(1280, 1024, 1.0). The square image demanded by 
RiFrameAspectRatioO .0) crops the raster to 1024 x 1024 and 
specifies the square screen window shown. The declared crop 
window runs from .125 to .75 horizontally and .125 to .5 verti- 
cally, excluding an eighth of the target raster at the left and 
top, a quarter at the right and half at the bottom. Assuming 
that "mydisplay” is 640 x 480 pixels, the rendered image is re- 
duced even further. 

It might seem strange to format an image so much larger than 
the display. However, it makes sense if one is developing a 
very large image and testing small parts of it by rendering 
them to a display. 

Summary of output specification 

To summarize, the rectangular region of pixels actually ren- 
dered represents the intersection of: 
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Figure 8.6 Pixels actually rendered for one set of imaging calls 


• the frame/ 

• the crop window, and 

• the display, if any. 

If output is to a file, the crop window is usually rendered in 
its entirety, although some file formats may have limited res- 
olution. No pixels at all will be rendered if the crop window 
occupies a part of the frame outside the display. 

Figure 8.7 summarizes how the frame and screen window are 
determined. Each box shows a factor in this process, and each 
factor has a priority list for determining its value. The lowest 
level has the lowest priority. This should enable the user to 
predict the effect of any given set of commands. The order of 
the various formatting commands within a program is irrele- 
vant; since the output image is not determined until scene de- 
scription begins with RiWorldBeginO, only the priority of the 
routines matters. 
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Figure 8.7 Arriving at rendered pixels 


The single most important factor in Figure 8.7 is the frame as- 
pect ratio. It determines the default screen window and abso- 
lutely determines the shape of the frame irrespective of the 
shape of the image or display. 

Pixel aspect ratio 

RenderMan assumes that pixels are square by default (in oth- 
er words, the default pixel aspect ratio is 1.0). However, if Ri- 
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DisplayO is called to send output to a display device, then the 
pixel ratio of the display prevails. The pixel aspect ratio given 
to RiFormatO has higher priority in case of conflict, but only if 
it is specified to be positive. (It might be negative or zero if 
one wishes to dictate the resolution with RiFormatO but leave 
the pixel aspect ratio alone.) 

Image resolution 

The default output image resolution is 640 pixels horizontally 
and 480 vertically, giving a frame aspect ratio of 4:3 (assuming 
square pixels). The default dimensions of the output image 
can be overridden by either RiDisplayO or RiFormatO. If both 
are called, the size given by RiFormatO has priority. RiDisplayO 
affects the size of the output image the output image only if it 
directs output to a physical display device (i.e., its type parame- 
ter is R1_FRAMEBUFFER). 

Frame aspect ratio 

If there is no call to RiFrameAspectRatioO, the frame aspect ra- 
tio is calculated from the resolution and pixel aspect ratio of 
the output image as 

ar*resi, 
ar,= P h _ 

i res 

v 

where ar p is the pixel aspect ratio, and res ^ and res v are the hori- 
zontal and vertical resolution of the image. 

The frame aspect ratio determines both the default screen win- 
dow and the actual frame. The default screen window con- 
tains the unit square on the image plane, widened or length- 
ened to match the frame aspect ratio. It can be set directly us- 
ing RiScreenWindowO. The frame is the largest area of pixels 
in the output image which has the stipulated frame aspect ra- 
tio. 

Once the screen window and target raster are defined, the rela- 
tionship between pixels and the screen window is fixed, and 
the Tenderer will attempt to calculate those pixels using that 
screen window. A subset of those pixels will be rendered if ei- 
ther RiCropWindowO is called or the target raster does not fit 
into the display used. 
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Synthetic camera model 

Figure 8.8 is a graphic representation of the discussion of this 
chapter. It indicates a significant difference from the physical 
camera model. In a physical camera, light converges on a focal 
point or viewing location, then projects onto an image (film) 
plane behind the focal point. The synthetic image plane is best 
visualized in front of the viewpoint. Specifically, RenderMan 
posits an image plane located at z=l, which leads to a more in- 
tuitive coordinate space: using an image plane in positive z 
means that the image is right-side-up after projection (unlike 
a conventional camera), and that the y axis is still positive up- 
ward. 

A Better Viewing Program 

Listing 8.5 shows a revised version of Listing 8.1. It uses 
FrameCameraQ and PlaceCameraQ as well as a set of pre- 
defined constants to set parameters. These have the default 
values for the corresponding options. This program may be 
used by modifying these parameter values and defining a 
scene between RiWorldBeginQ and RiWorldHndQ. 
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Figure 8.8 Projection into screen space ( earner Q-to-r aster projection geometnj) 


^include <ri.h> 

A viewbasics.c: file compiling view options into a rendering shell. */ 
^define FILENAME "ri.pic" A output file name; delete to render to display */ 


^define DATATYPE RLRCBA 
^define PJCXRES ( ( Rtlnt ) 640 ) 
^define PICYRES { { Rtlnt ) 480 ) 

Sderine CROPMINX ( ( RtFloat ) 0.0 ) 
#define CROPMAXX ( ( RtFloat ) 1.0 ) 
^define CROPMINY ( ( RtFloat ) 0.0 ) 
#define CROPMAXY ( ( RtFloat ) 1 .0 ) 
^define CAMXFROM 0.0 
# define CAMYFROM 0.0 
ndefine CAMZFROM 0.0 

^define CAMXTO 0.0 
#derine CAMYTO 0.0 
"define CAMZTO 1 .0 


A Pixels have RGB and coverage */ 
A Horizontal output resolution */ 

A Vertical output resolution */ 

A RiCrop Windo w() pa rameters */ 


A Camera position */ 


A Camera direction */ 
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#define CAMROLL 0.0 


/* Camera roll 


■ . w - 44- 




V 


^define CAMZOOM 1 .0 /* Camera zoom rate */ 

RtPoint CameraFrom = ! CAMXFROM, CAMYFROM, CAMZFROM }, 
CameraTo = I CAMXTO, CAMYTO, CAMZTO 1; 


mainO 


RiBegin( RI_NULL ); /* As always */ 

/* Output image characteristics */ 

#ifdef FILENAME /* output to file V 

RiDisplay(FILENAME, RI_F!LE, R1_RGBA, RLNULL); 

#e!se /*...to frame buffer “/ 

RiDisplay( RLFRAMEBUFFER, RI.RGBA, RLNULL); 

#endif 

RiFormat{ PICXRES, PICYRES, 1 .0 ); /* Image resolution */ 

/* Region of image rendered V 
RiCropWindow( CROPMINX, CROPMAXX, 

CROPMINY, CROPMAXY ); 

/* Camera characteristics */ 

FrameCamera( (float)PORES' , CAMZOOM, (float)PICXRES, 
(float)P!CYRE$ ); 

/* Camera position and orientation V 
CameraTofOj -=• CameraFrom [0] ; 

CameraTo[l j -= CameraFrom(1 ]; 

CameraTo(2! -= CameraFrom [2]; 

PlaceCameraC CameraFrom, CameraTo, CAMROLL ); 

RiC!ipping( RLEPSILON, Rl JNFINITY ); /* Clipping planes’/ 

/* Now describe the world */ 

RiWorldBeginO; 

/* ... Your scene here... */ 

RiWorldEndO; 

RiEndO; 

\ 

Listing 8.5 An improved boilerplate viewing program 
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CHAPTER 9 


Viewing II: A Model of 
the Rendering Process 


nrL ‘* * 1 --pter rounds out the discussion of camera spec- 



Chapter 8 presented the viewing process in 


I terms of a physical camera, a model that is sufficient 
for many cases. However, there are enough differences be- 
tween the physical model and the way digital rendering 
works that the physical model breaks down eventually. This 
chapter concerns general issues of quality arising from the dig- 
ital image synthesis process. The first section addresses the ex- 
actness of curved surface representation. The second covers 
the process of producing the pixels of an image. The last two 
sections introduce two of the most novel features of the Ren- 
derMan Interface: motion blur and depth-of-field calculations. 

Surface Approximation 

The first quality issue concerns the approximation of curved 
surfaces. Under many rendering schemes, for example, poly- 
gons are much easier to render than curved surfaces, so quad- 
ric or parametric surfaces may be approximated by the Tender- 
er using small polygons. As the number of polygons goes up, 
so does the quality of the approximation, but so does the cost 
of creating, storing and rendering the polygons. Ideally, the ap- 
proximation should be adaptive: a more tightly curved sur- 
face needs more small polygons than a smoother one for the 
same quality of approximation. Different measures of "qual- 
ity" may also apply in different situations. 

RenderMan provides a routine for determining whether a set 
of polygons or other surfaces constitutes an adequate approxi- 
mation to the underlying surface. 
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RiGeometricApproximation( type, value ) 

RtToken type; 

RtFloat value; 

RiCeometricApproximationO sets the criterion for approximat- 
ing the surface primitives of a scene with other, more easily 
rendered, primitives, type is the type of criterion and value 
gives a value in a metric meaningful for that criterion. There 
is one predefined type, "flatness" (RI_FLATNESS), the default, 
under which a polygon is a good enough approximation if it 
never deviates more than value pixels from the true curved 
surface in raster space. 

The default value is .5, so that no polygon deviates by more 
than half a pixel from the surface it is approximating. 


Raster Output 

Now that we know how the geometry of a scene is projected 
onto a raster image, the only remaining question is how the 
parts of the scene landing near a pixel affect the color and in- 
tensity of the pixel as output. We need to discuss how that 
output is determined, again beginning with a conceptual mod- 
el to help understand just what is going on. 

Model of pixel rendering 

An image formed using RenderMan is a raster, a rectangular 
grid of pixels, which represents the scene data projecting in- 
side the screen window on the image plane. To physically dis- 
play an image, each pixel supplies color information for light- 
ing the phosphors of a cathode-ray tube or for controlling a 
color halftone. It is essential to realize, however, that the sin- 
gle color value at a pixel represents a finite area of the image 
plane, which may contain a variety of surfaces. Its color may 
actually vary a great deal across its extent Generating an out- 
put pixel value, then, requires analyzing the scene informa- 
tion at the pixel, settling on an external representation for the 
result, and possibly supplementing the color with other kinds 
of information. 


172 


Chapter 9: Viewing II: A Model of the Rendering Process 


Sampling 

Rendering a pixel begins with the very small portion of a 
scene that projects onto the target raster near the center of the 
pixel. It must produce a single color value for that pixel; that 
is, it must sample the scene. 

In the simplest methods, the scene data is simply point sam- 
pled: the color of the entire pixel is taken from the surface at 
the center of the pixel. Point sampling invariably diminishes 
image quality with aliasing artifacts. RenderMan supports a 
variety of methods for filtering the scene geometry, in order 
to improve the quality of the resulting image by allowing 
more surface information to influence the output pixel. 

Quantization 

Once the color at a pixel is determined, it is usually quan- 
tized, or reduced to a small set of discrete colors. These are typ- 
ically represented using a range of integers, usually [0,255], in 
which integer steps represent equal differences in the original 
color. In other words, quantization is a linear mapping by de- 
fault. 

This linear quantization has shortcomings of its own, since it 
leads to high contrast between adjacent quantized values at 
low levels.* RenderMan directly supports logarithmic expo- 
sure mapping, and provides the ability to specify any other 
function for converting pixel colors for output. These could 
be used to convert to other color systems before quantization. 

Associated image information 

Finally, RenderMan allows information other than color to 
be output. The depth in space of the surface projecting onto a 
pixel (its z value) can be made available using RiDisplayO, for 
use in combining images with hidden-surface resolution. It 
may also be important to record the fraction of a pixel that 

*A good measure of the contrast between values C } and C, is 
C - C 

Cj+ c 2 

Values near 0 have much higher contrast than higher values. 
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surfaces from the scene (its alpha value), in order to compos- 
ite images accurately. 

The imaging pipeline 

Figure 9.1 expands on the above model to show the pixel pro- 
duction process schematically. It begins once the projection 
and hidden-surface processes have determined the scene in- 
formation projected in the vicinity of the pixel. Two paths 
proceed in parallel, one for color values and one for depth val- 
ues. We'll discuss each stage in the pipeline together with the 
routines that govern it. 

Filtering and sampling 

The process of choosing an output value to represent the part 
of an image under a pixel is known as sampling. The most 
common method of sampling is simply to determine the col- 
or of the light arriving from the scene in the center of the pix- 
el. This creates problems in realistic rendering, since fine de- 
tail (a tiny picket fence is the usual example) that is too small 
to be resolved can nonetheless create huge, inappropriate fluc- 
tuations in adjacent pixel values (aliasing), depending on 
which part of the detail falls on the pixel center. The staircas- 
es, or jaggies, that are seen along edges that are close to being 
horizontal or vertical are a familiar artifact of primitive sam- 
pling. 

The ideal is to completely integrate all that lies under a pixel 
into the sample, carefully affording each surface its due in the 
output pixel value. Unfortunately, this process is extremely la- 
borious, impractical and sometimes impossible to perform 
correctly. In practice, computer graphics falls back on a num- 
ber of compromises that offer improvements over point sam- 
pling at reasonable cost. 

One strategy is to supersample the pixel: compute the arriv- 
ing colors at several regularly spaced locations inside the pixel 
and filter, or weight the resulting values to obtain the pixel 
value. This strategy, too, has disadvantages, beginning with 
the fact that it multiplies the cost of computing the image 
without increasing its resolution. Supersampling can only re- 
duce aliasing, not eliminate it. Nevertheless, it does qualita- 
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Figure 9.1 The imaging pipeline 


tively improve the picture. Furthermore, aliasing artifacts can 
be converted to much less noticeable noise by jittering the su- 
persamples (randomly displacing them individually from 
their uniform placement) [COOK86]. 
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RiPixelSamplesf xsamples, ysamples ) 

RtFloat xsamples, ysamples; 

The parameters of RiPixelSamplesO give the ratio of the num- 
ber of samples taken to the number of pixels in each direction. 
The default is 2 samples in each direction, meaning that each 
pixel contains 4 samples. 


Filtering the supersamples 

The final output value of a pixel is a weighted average of the 
supersamples. Generally, the farther a sample from the cen- 
ter, the less its weight. Specifically, a filter function gives sam- 
ple weight as a function of x- and y-displacement. 

All practical filter functions decrease to zero at some distance 
from the pixel center. Otherwise, all of space would have to be 
sampled to compute one pixel. The width of this support of 
the function may be greater than the size of a pixel. In other 
words, the samples that go into a pixel can come from the 
"grid cells" of nearby pixels. This can increase the quality of fil- 
tering at little additional expense, since a single sample can be 
used on a number of pixels. 


RiPixelFilterf (unction, xwidth, ywidth ) 

RtFloatFunc function; 

RtFloat xwidth, ywidth; 

Pixel filter functions are specified by passing a pointer to a 
function returning an RtFloat value (see below), xwidth and 
ywidth specif}’ the support of the filter in pixels. The weight of 
a filter is 0 outside its support. A w’idth of 1 means that only 
samples within the grid cell of a given pixel w’ill influence 
that pixel. 

The five filter functions RiGaussianFilterO (the default), RiBox- 
FilterO, RiTriangleFilterO, RiSincFilter() and RiCatmullRomFii- 
ter() are defined with RenderMan. Each function weights sam- 
ples according to their distance from the pixel center. 
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Figure 9.2 Standard Render Man filter functions 


Samples affect a pixel from a two-dimensional area whose ex- 
tent is xwidth in x and ywidth in y. Assume that F(x,y ) is a two- 
dimensional filter function. A sample at position (x,y) relative 
to the pixel center is weighted (scaled) by F(x,y) if 

-(xwidth/ 2) < x < (xwidth/ 2) 

and 

-(ywidth/2) < y < (ywidth/ 2), 

and 0 otherwise. For the sine and Catmull-Rom filters, some 
samples have negative weight. 

Figure 9.2 shows the standard filter functions in one dimen- 
sion. In two dimensions, the triangle and box filters are bilat- 
erally symmetric, i.e., the triangle becomes a pyramid and the 
box a cube. The other filters are circularly symmetric. Formal- 
ly, if fix) is a one-dimensional filter function, then 

F(x,y) = min(/(.r),/(y)) 

for triangle and box filters, and 

F(x,y) = /(sqrt(.r 2 +y 2 )) 

for Catmull-Rom, sine and Gaussian filters. 
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The xwidth and ywidth parameters to RiPixelFilterO affect differ- 
ent filter functions differently. The triangle, box and Gaussian 
filters are widened or narrowed so that they are nonzero with- 
in the specified bounds and zero outside. The sine filter, on 
the other hand, is clipped: the filter always has the same 
shape, and its width only determines the bounds over which 
it is evaluated. A width of 2 means that each sample is given 
a non-negative weight, for example. The Catmull-Rom filter 
is also clipped. 

Other filters can be programmed by the user and passed to the 
interface. They are declared as follow's: 

RtFloat filterfuncf x, y, xwidth, ywidth ) 

RtFloat x, y; 

RtFloat xwidth, ywidth: 

x and y give a displacement from the pixel center, w'here pixel 
centers are a distance of 1.0 apart, xwidth and ywidth give the 
filter support passed to RiPixelFilterO. filterfunc should return 
the weight of the filter (usually a value between -1 and +1) at 
that point. 


Typically, filterfunc is called only enough times to build up a 
table of filter weights. It is never called with abs(x) > xwidth/2 
or absiy ) > ywidth/2. 

Pixel fidelity 

RiPixelSampIesO directly determines how’ frequently the scene 
is sampled. Usually, the higher the sampling rate the better 
the image quality. However, the sampling rate can be made 
adaptive. Portions of an image wTiose shade varies relatively 
slowly can be sampled less frequently, hence more efficiently. 
Conversely, image areas of greater detail can be sampled more 
frequently, hence more accurately. Adaptive sampling is a 
way to put rendering effort where it will do the most good. 

RiPixelVarianceO is a more general and flexible way to specify 
sampling rate than RiPixelSampIesO. For a given set of sam- 
ples, the accuracy of the resulting pixel value can be statistical- 
ly estimated; increasing the number of samples decreases this 
variance of the sample from the true value. The sole parame- 
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ter of RiPixe!Variance() dictates an acceptable level of variance. 
More samples are taken at a pixel until the variance is below 
the requisite threshold. 


RiPixelVariancei variance } 

RtFloat variance; 

RiPixelVarianceO limits the acceptable variance in the output 
value of pixels. The variance parameter is expressed before 
quantization. For example, if pixel values are normally be- 
tween 0 and 1, a variation of 1/255 in the context of 8-bit quan- 
tization will mean that the pixel as output should not vary by 
more than one quantization level. 


Since it is based on statistical methods of predicting the likely 
deviation of a pixel value, the sampling criterion of RiPixeiVa- 
rianceO is probabilistic. However, it is predictable in the sense 
that lowering the variance will improve the overall quality of 
a picture. 

Exposure 

After a single (color) value is derived at a pixel, it enters the 
second step of the pixel production pipeline, exposure, in 
which pixel values are passed through an arbitrary’ function 
that models the rendering system's "response" to incoming 
light. 

Every sensor of light responds according to the amount of im- 
pacting light. This relationship is not always, or even usually, 
linear. Photographic film, for example, increases in density as 
a logarithmic function of the total light striking it. Render- 
Man supports such nonlinear encodings of color data in order 
to serve better the needs of both display technology and the 
human visual system. 

Considering for a moment the display of an image, cathode- 
ray tube monitors are driven by applying a voltage to each of 
its red, green and blue electron guns. The intensity of the re- 
sulting colors is nonlinearly related to the applied voltage. In 
fact, the output intensity I approximates a power curve in in- 
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put voltage V: 1-V^, for some y different for each type of moni- 
tor. Often a display has a lookup table accompanying its image 
memory that can be used to compensate for this characteristic. 
It is also possible to perform this compensation in the render- 
ing stage, although that makes the resulting image more spe- 
cific to the target display. 

Perhaps the most compelling reason for nonlinear encoding 
concerns the discrimination capabilities of the human eye. In 
a linear encoding, the difference of brightness from one quan- 
tization level to the next is constant. But by the time the visu- 
al information on the surface of a monitor passes through the 
human visual system, the perceived difference between two 
levels of brightness is related less to their absolute difference 
than to their proportion. As a result, the perceived difference 
between intensity levels of 3 and 4 is far greater than that be- 
tween 200 and 201. A nonlinear encoding of brightness data of- 
fers the opportunity to make the best use of the bits of output. 


RiExposure( gain, gamma ; 

RtFloat gain, gamma; 

After a call to RiExposureO, even' color component of ever)' 
pixel is transformed as follows: 

co\or 0utput = (color input *gain) Vgamma 

gain and gamma must be positive. Each is 1.0 by default, mean- 
ing in essence that exposure mapping is turned off in the nor- 
mal case. 


Figure 9.3 shows input vs. output for gamma > 1. If the output 
is quantized into sixteen levels, as shown, then the quantiza- 
tion levels will be distributed as shown on the ordinate, clus- 
tered at the lower intensity levels. Nonlinear exposure is a rel- 
atively cheap way to improve the apparent color resolution of 
a display system. 

Figure 9.4 demonstrates the effect of changing gain and gam- 
ma . Each column was rendered with identical gain, and each 
row with identical gamma . From left to right, the columns 
have gain of 0.5, 1.0 and 2.0. gamma goes from 0.5 on the top 
row to 1.0 in the middle and 2.0 on the bottom. 
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Shaded pixel values 


Figure 9.3 Effect of quantizing pixel values after gamma-mapping 


Imaging 

After exposure, the color components of a pixel are passed 
through an imaging process. This allows users to modify out- 
put pixel values in any way they choose. 


Rilmager( name, parameterfist ) 
char *name; 

The name passed to RilmagerO refers to a shader written in 
the RenderMan Shading Language, parameterlist is a series of 
token-value pairs used to pass parameters to the shader. 

The imager shader is an option, and so cannot be set after Ri- 
WorldBeginQ. 



By writing an imaging shader and invoking it with Rilmag- 
erO, a user has a chance to transform the colors of output be- 
fore quantization. For example, if output is intended for color 
separations, an imaging shader might convert RGB coordi- 
nates into CMYK output, placing the cyan, magenta and yel- 
low coordinates into the RGB components, and black into al- 
pha. The user could also use an imager to implement a more 
sophisticated exposure mechanism than that provided by 
RiExposureO. 
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Figure 9.4 Results of RiExposure(): gain increases from left to right, gamma 
from top to bottom 


Quantization 

For realistic imagery, pixel values may be calculated at high 
resolution, often up to 32 or 64 bits per channel. Only rarely 
do they need to be stored with such precision, especially since 
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few displays can present data with more than 10 bits of color 
resolution per channel. The format of the data also matters, 
since even fewer displays handle anything but integer values. 

As a result, almost all images are stored using low-resolution 
fixed-point numbers to represent the color values at each pix- 
el. There are two basic aspects of mapping from floating-point 
values to integer format: what range of floating-point values 
maps to what range of integer values, and how the errors asso- 
ciated with this mapping can be reduced. 


RiQuantize( type, one, min, max, ditheramplitude ) 

RtToken type; 

Rtlnt one, min, max; 

RtFloat ditheramplitude; 

RiQuantizeQ is used to specify quantization and dithering. It 
may be called independently for color values and depth val- 
ues. type should be the token "rgba” (RI_RGBA) for the former 
and M z" (RLZ) for the latter. 

When quantization is turned on, the floating-point values at 
each pixel are assumed to lie in the range [0,1]. Each channel 
value is multiplied by one, and the resulting integers are 
clamped to the range [min, max]. In other words, if fvalue is the 
computed value of a channel, then the corresponding quan- 
tized value is 

ivalue = fvalue* one 

This maps the range [0,1] into the range [0 ,one]. If ivalue<min , 
then clamping raises ivalue to min; if ivalue>max, then it is low- 
ered to max. 

ditheramplitude can be used to introduce a little randomness 
into the pixel value before quantization. If randomO is a func- 
tion generating a random number between -1 and 1, then 

ivalue - fvalue* one + ditheramplitude*random() 

ivalue is then clamped as before. 

ditheramplitude is 0.5 by default, which randomly perturbs the 
output by one quantization level up or down. 
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For example, the call 

RiQuantize( RI_RGB, 255.0, 0, 255, 0.0); 

quantizes the red, green and blue channels of an image with- 
out dithering. It maps the range [0,1] into the integer range [0, 
255], suitable for storage at eight bits per channel. If, instead, 
the channels were calculated in the range [0,255], then 

RiQuantizef RI_RGB, 1 .0, 0, 255, 0.5); 

would provide the proper quantization, and also dither the 
pixel values before quantization. 

Dithering and false contours 

The contrast (ratio of intensities) between adjacent fixed-point 
values is very high for values near zero. Very dark, slowly- 
varying surfaces may have large adjacent regions with high 
contrast between them, which may be seen as false contours 
in the image (see Figure 9.5). This is a problem largely because 
the human visual system emphasizes contrast, and it is espe- 
cially troublesome for quantization to a fixed-point range 
with low resolution. The nonlinear encoding provided by Ri- 
ExposureO can help, but it is no panacea. 

One solution to the contouring problem is to dither pixel val- 
ues by adding a random amount of noise before quantization. 
A proper dither will thus perturb the resulting fixed-point val- 
ue by a step up or down at random. While this doesn't mean 
much at the level of a single pixel, adjacent groups of pixels 
will vary in their average intensity according to their mean 
floating-point value. This group average has considerably 
more resolution than the color of a single pixel. 

This style of dithering can be invoked by setting the ditheram- 
plitude parameter of RiQuantizeO to a nonzero value (0 turns 
dithering off). Typically the noise range should randomly 
round the pixel value up or down to the next level. This is ac- 
complished by using a ditheramplitude value of 0.5, as in the 
example above. 

We have now covered all RenderMan routines that address 
the pixel production process. Now we can step back and 
present two large-scale quality issues: the fact that physical 
cameras have a limited ability to resolve detail in space, and 
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Figure 9.5 False contours (left); contouring reduced by dithering (right) 


in time. These artifacts are introduced into synthetic images 
via depth-of-field calculations and motion-blur effects. 

Depth of Field 

Cameras that focus light through a finite-sized aperture ren- 
der objects sharply over only a limited range of distances. The 
sharpness of an object in a photograph depends on its distance 
relative to that range. The extent of the range of acceptable fo- 
cus is related to the diameter of the lens opening, or aperture: 
the smaller the opening, the wider this depth of field. The 
uniformly perfect focus of most computer images may be en- 
viable to photographers, but it does eliminate an esthetic tool 
and a cue for depth perception. 

A photographer sets the optical system of a camera to a focal 
distance at which objects appear sharpest. The depth of field 
is then determined by 1) the ratio of the focal length to the 
size of the aperture admitting light into the camera (the f- 
stop), and 2) the focal distance. 


RiDepthOfField( fstop, focallength, focaldistance ) 

RtFloat fstop, focallength, focaldistance: 

The parameter focaldistance to RiDepthOfFieldO gives the dis- 
tance at which surfaces appear in focus, focallength declares 
the focal length of the lens being used, fstop declares the f-stop 
to which the lens is set. An fstop of RIJNFINITY, the default. 


1 •• 
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signifies a pinhole camera rendering objects equally well-fo- 
cused everywhere in the world, turning depth of field off. 


In photography, the focal length of a lens is commonly ex- 
pressed in millimeters, but the units used in focallength are 
unimportant; they need only be the same as the units used for 
focaldistance. 

Figure 9.6 shows the effect of varying the f-stop of an image. 
The three panels were generated with identical data; the only 
variation was the f-stop, which was fl .4, /8, and f22 at the top, 
middle, and bottom, respectively. 

Motion Blur 

A camera that could record a scene with perfect sharpness, no 
matter how quickly objects or the camera moved might seem 
like an enviable technical achievement. However, a series of 
perfectly sharp images, when presented in rapid sequence as 
an animation, creates a strobing effect, destroying the sense of 
smooth motion. Objects needn't be blindingly fast to suffer 
from this temporal aliasing: the eye expects to see a loss of de- 
tail in moving objects. Even in a single image, a little 
"streaking” of a moving object can give a sense of dynamics. 

Plate 24 shows a frame from the animated film Luxo Jr. in 
"Light Entertainment." Part of the satisfying sense of physical 
realism in that film arises from the motion blur used for 
even the smallest movements. 

Specifying motion blur 

A photograph may appear blurry because objects, lights or the 
camera move while the shutter is open. For a synthetic scene, 
this movement is set out explicitly by 1) defining the scene's 
geometry at a series of moments in time, and 2) specifying the 
time period the shutter is open. Each of the geometry defini- 
tions represents a temporal sample of the changing scene con- 
figuration at one moment. For times in between, the parame- 
ters of the objects in the scene are interpolated between adja- 
cent sample moments. The nature of the interpolation 
(linear, cubic, etc.) is left up to the implementation. 
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Figure 9.6 Effect off-stop on depth of field. Focal length and distance were fixed, 
but f-stop was varied from 2.4 at top to 8 in the middle to 22 at bottom. 


Moving the scene 

There are two basic approaches to describing changes in a 
scene over time. The first would involve a complete descrip- 
tion of the entire scene at each sample moment; i.e., "here's 
the scene at time tj; here it is at t?, here's..." Presumably ail the 
values of the scene (positions, light colors, etc.) that differed 
from one time to another would be interpolated. 
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RenderMan takes a different approach. Rather than move an 
entire scene between times, the scene is described once, but the 
moving objects and/or transformations are described several 
times, with their parameters changing from one time to the 
next. For example, a geometric translation can be declared at 
time f] and time *2 . In between those two times, any object af- 
fected by that translation will move smoothly between the 
two positions resulting from the translations at the extremes. 

Using this parameter interpolation technique, the geometry 
of objects themselves may also vary over time. For example, 
if a polygon command is declared at two different times, the 
two versions are matched vertex for vertex, so that the poly- 
gon's shape, as well as its motion, may change. A sphere can 
have one radius, top, bottom and sweep angle at one time and 
another set of parameter values at another time. In between 
times, it will interpolate smoothly between the extremes. The 
latter change would be difficult or impossible to describe cor- 
rectly using interpolation for an entire scene because poten- 
tially complex motion information would be lost. 

The time-varying parameter approach has three advantages. 
First, it is only necessary to describe those parts of the scene 
that actually change. Second, each part can be sampled differ- 
ently. For example, an object moving along a tight curve may 
need many samples to correctly approximate its motion. An- 
other object in the same scene might be moving along a 
straight line, requiring only two samples. Third, motion can 
be interpolated in the semantically appropriate way: the inter- 
polated rotation of a point can be very different from the end- 
points of the rotation, interpolated. 

Declaring motion 

The basic method for moving objects or commands is simple: 
they are declared exactly as usual, with the same RenderMan 
procedure calls. Each routine to be moved is replaced by a se- 
ries of calls to the same routine, with any time-varying param- 
eters changing from one call to the next. This series of proce- 
dure calls is identified as a series of time samples, rather than 
independent static calls, by bracketing this motion block with 
calls to RiMotionBeginO and RiMotionEnd(). The former rou- 
tine also spells out the time associated with each procedure 
call in the block. 
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RiMotionBegin( N, timel, ..., timeN ) 

Rtlnt N; 

RtFloat timel, ..., timeN; 

RiMotion£nd( ) 

A RenderMan Interface procedure is sampled over a sequence 
of N times by calling RiMotionBeginO, calling the procedure ex- 
actly N times, and finishing with RiMotionEndO. RiMotionBe- 
ginO declares N, the number of samples, and the time of each 
sample. The first is assumed to take place at time 7, the second 
at time2, etc. The time values time!.. .timeN must increase 
from one to the next. If an implementation does not support 
motion blur, then the sample at timel is used. 

Within the motion block there should be exactly N calls of ex- 
actly one RenderMan procedure. Moving three routines, 
even over the same interval, requires three motion blocks. 


Examples 

If a transformation is given different values at different times, 
all objects affected by that transformation will move over 
time. For example: 

RiT ransformBeginO; 

RiMotionBegin( 2, 0.0, 1.0 ); 

RiRotate( 10.0, 1.0, 0.0, 0.0 j; 

RiRotate( 20.0, 1 .0, 0.0, 0.0 ); 

RiMotionEnd( ); 

RiSphere( 1.0, -.7, .7, 270.0, RI_NULL <; 

R iTransform End (); 

The clipped sphere will be rotated by ten degrees about the x 
axis at timel, and rotated twenty degrees at time2. In between 
times, the amount of rotation will vary smoothly between ten 
and twenty degrees. 

The motion block above is similar to a single rotate com- 
mand. Any RenderMan commands could appear between Ri- 
MotionEndO and RiTransformEndO, including object descrip- 
tions, light sources, environment modifications and transfor- 
mations. Any object affected by the current transformation 
would be moved in time. 
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Moving objects 

Object declarations are moved in a similar way: 

RiTransformBeginO; 

RiRotate{ 10.0, 1.0, 0.0, 0.0 ); 

RiMotionBegin{ 2, 0.0, 1.0 ); 

RiSphere( 1 .0, -.7, .7, 270.0, RLNULL ); 

RiSphere( 1 .0, 1.0, 1.0, 360.0. RLNULL ); 

RiMotionEnd{ ); 

RiTransformEndO; 

This time it is the definition of the sphere that moves. Be- 
tween time 0.0 and time 1.0, the sphere is closed at the top and 
bottom, and its sweep is completed. 

Opening and closing the shutter 

RiMotionBeginO and RiMotionEndQ define the time-varying be- 
havior of a scene. The procedure calls in a motion block de- 
fine the exact configuration of the scene at any time within 
the intervals. Only one other piece of information is required: 
the interval of time over which the shutter is open. 


RrShutterf opentime, closetime ) 

RtFloat opentime, closetime; 

RiShutterO declares when the virtual shutter opens and when 
it closes, opentime and closetime can be any times at all, as 
long as opentime < closetime. If opentime - closetime, the 
scene is defined for the fixed configuration at t = opentime , 
and no motion blur is done at all. 

The open shutter interval is applied to an image as a whole. 
Therefore it must be specified before RiWorldBeginQ. 


The shutter times should resemble the times declared for the 
moving primitives. If opentime < timej or closetime > time^j 
for some primitive's timej and time no guarantee is made as 
to the primitive's position. 
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What can move 

Not all procedures can appear within a motion block. For ex- 
ample, since options are fixed for an entire image, it makes no 
sense to blur them. The set of commands allowed inside a mo- 
tion block are listed in Table 9.1 below. In general, any float- 
ing-point parameter values of geometry or attributes may 
change. 


Transformations 

Geometry 

Shading 

RiTransformO 

RiBoundO 

RiColorQ 

RiConcatT ransformO 
RiPerspectiveO 

RiDetaiJO 

RiOpacityO 

j j 

RiDisplacementO 

RiSphereO 

RiLightSourceO 

RiDeiormationO 

RiConeQ 

! RiArealightSourceO j 


RiCylinderO 

RiSurfaceO 

RiTransiateO 

RiHyperboioidO 

Ri!nterior() 

RiRotateO 

RiParaboloidO 

RiExtenorO 

RiScaleO 

RiDiskO 

RiAtmosphereO 

RiSkewO 

RiTorusO 

RiPolygonO 

RiGeneralPolygonO 

RiPointsPolygonsO 

RiPointsGeneralPolygonsO 

RiPatchO 

RiPatchMeshO 

RiNuPatchO 

i 

j 

! 


Table 9.1 Time-variable Render Man Procedures 

Further Research 

The sampling process and filtering theory involve some of 
the most elegant mathematics around. Frank Crow [CROW77] 
first pointed out the aliasing problem in synthetic imagery. 
Two recent articles that treat the problem in the context of 
computer graphics are [DIPPE85] and [COOK85]. An excellent 
text encompassing concepts of analog and digital signal pro- 
cessing is [OPPEN75]. Finally, a full treatment is [PRATT78]. 

On the lighter side, the credibility added by good motion blur, 
and the degradation resulting from nonexistent motion blur, 
can be seen in the stop-motion animation of popular films. 
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CHAPTER 10 


Procedural Models and 
Level of Detail 


r . The surface types set out in chapters 4, 5 and 6 can be 
* used to represent a wide variety of objects. However, a 
given object may lend itself to many valid representa- 
tions varying from the crudest to the most detailed. For exam- 
ple, a curved surface can be approximated using a number of 
polygons. The number of polygons used for a given surface af- 
fects both the amount of data the Tenderer must deal with and 
the quality of the resulting image. If the polygons approximat- 
ing a curved surface are only about a pixel in size, then the ap- 
proximation may be indistinguishable from the real thing. At 
the other extreme, a bicubic patch can be approximated very 
crudely by the nine bilinear quadrilaterals defined by its con- 
trol hull. 

This trade-off between quality and complexity is not static, but 
depends in part on the viewing parameters of an image. Even 
approximating a parametric surface with its control hull may 
be appropriate if the surface occupies only a few pixels. Con- 
versely, it can be wasteful to use detail that gets lost between 
the pixels. We already saw in Chapter 9 that Tenderers often 
make this trade-off in splitting curved surfaces into polygons 
for rendering, subject to some quality criterion. 

There is an analogous problem with models as a whole. For 
example, does one depict a tree trunk with a cylinder, or with 
an elaborate curved surface? If the tree is so small in the out- 
put image that the two are indistinguishable, the answer is ob- 
vious. 

With viewing functionality residing on the other side of the 
interface, how can an application determine the best way to 


approximate its models with RenderMan primitives? A more 
intimate relationship must be established between the soft- 
ware defining a scene and the Tenderer producing the image. 

A model's definition should vary according to its size as mea- 
sured in pixels. The RenderMan Interface supports two differ- 
ent means to this end. The first, discussed in the next section, 
allows the application to specify several alternative represen- 
tations for a model and let the renderer choose between them. 
The model chosen in a particular rendering depends on the 
on-screen size of the object (its level of detail), with a smooth 
transition between alternatives. 

The second method is more general, hence more flexible, but 
also more involved for the application. It defines an object, 
not as a data structure containing geometric coordinates, but 
as a procedure invoked by the Tenderer. This procedure then de- 
clares the geometric data according to image information the 
Tenderer passes to it. This gives the application an opportuni- 
ty to define its objects in the context of rendering. These proce- 
dural models are covered in the second section of this chapter. 

Level of Detail Calculations and Models 

There is an important trade-off in image synthesis between 
the complexity that can provide visual interest, and the cost 
of rendering complex objects. Many applications work well 
with a simple representation for a model if it is far away, but 
require a more complex version when it looms larger. Rather 
than always forcing the application to pay for rendering the 
most complex available representation, RenderMan allows a 
set of alternatives to be specified, then chooses the appropriate 
one based on its apparent size in the image. Varying the com- 
plexity of a model according to its apparent size is a key strate- 
gy for providing the right level of visual interest at reasonable 
cost. 

Support for level of detail calculations is an optional capabili- 
ty in the RenderMan Interface. Renderers that do not support 
it will simply ignore the information discussed below and al- 
ways draw the most complicated model. 
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Level of detail defined 


The apparent size of an object depends on several variables: 
the actual size of the object, its distance from the camera, the 
camera's field of view, and the resolution of the output im- 
age. Fortunately their net effect can be expressed as a single fac- 
tor, the number of pixels covered by the object in the image. 
We call this area in raster space the object's level of detail. 

Calculating level of detail 

All the imaging parameters that go into determining the lev- 
el of detail of an object are fixed by the time it is defined, but 
the object's size must be declared to the interface. 

Every object occupies a definite range [xmin...xmax] along the 
x axis, another range in y, and a third in z. The six orthogonal 
planes x=x min, x=xmax, y=ymin, y-ymax, z=zmin, z=zmax in- 
tersect to define a three-dimensional rectangular box barely 
enclosing the object. For simplicity, the level of detail calcula- 
tion for an object uses this bounding box: the box is projected 
onto the image plane, where the level of detail is calculated as 
the on-screen area of its bounding box. 

The level of detail of the bounding box is at least as large as, 
and usually larger than that of the object itself, especially for 
very diagonal, elongated objects. But the bounding box has 
the virtue of simplicity. 

Bounding box declaration 

The bounding box for an object is declared explicitly. 


RiDetaiK bound ) 

RtBound bound; 

RiDetaiK) declares a bounding box by giving the minimum 
and maximum x, y and z coordinates in bound in the order 
[xmin, xmax, ymin, ymax, zmin, zmax]. All points in bound 
should be in object coordinates. The interface calculates the 
level of detail of that bounding box and uses it to set the cur- 
rent level of detail. The larger the bounding box, the higher 
the level of detail. That value is an attribute in the graphics 
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state, so it applies to all subsequent objects declared within the 
same block. 


Level of detail metric 

A high level of detail demands a more detailed object than a 
lower level, but this is still just a relative measure. Some ren- 
derings of the same scene may require more detail than oth- 
ers. The interface allows the application to boost or diminish 
the relative importance of pixel area by declaring that all level- 
of-detail values should be scaled by a certain amount. This 
means that the rendered quality of an entire image can be con- 
trolled by a single parameter. 


RiRelatrveDetail( relativedetail ) 

RtFloat relativedetail; 

RiRelativeDetailO causes all level-of-detail values to be multi- 
plied by the factor relativedetail. A value greater than 1 causes 
models employing level-of-detail calculations to be rendered 
in greater detail; if it is less than 1, they are generally rendered 
more crudely. 

The relative level of detail is an option, so it must be declared 
before RiWorldBeginO, and it applies to an image as a whole. It 
cannot be adjusted for individual objects. 


Using level of detail 

An application controls the complexity of a model by present- 
ing a number of alternative representations for it, associating 
each with a range of level-of-detail values. The Tenderer 
chooses among the alternatives based on the current level of 
detail, as determined from the model's bounding box above. 

Presumably the simpler alternatives will be assigned to the 
lower ranges of detail, when the model occupies a small area 
of the image. The more complex alternatives will be used at 
higher levels, when the model appears larger and more detail 
is required. Depending on the implementation, the system 
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may either select one alternative to the exclusion of all others, 
or smoothly blend two alternatives. 

Level of detail declaration 

Each alternative is described as a series of surfaces and objects. 
Before presenting an alternative, its relevant range of detail is 
declared with RiDetailRangeO. 


RiDetailRange( oftlow, onlow, onhigh, ofthigh ) 

RtFloat onlow, onlow, onhigh, offhigh; 

RiLeveiOfDetailO prefaces one alternative representation for a 
model, and declares four level-of-detail values that specify the 
importance of the alternative at four different levels of detail. 
The special value RIJNF1NITY may be used for onhigh and/or 
offhigh to declare the most detailed alternative. 

The model has importance 0 for levels of detail below ofr'low 
and above offhigh. It has importance 1 for levels between on- 
low and onhigh. In the range of level of detail from offlow to 
onlow, the importance increases from 0 to 1. From onhigh to 
offhigh, it decreases from 1 to 0. 


Meaning of level of detail 

Figure 10.1 should help to illustrate the meaning of these 
ranges. Essentially, RiDetailRangeO says that the coming alter- 
native should be used at levels of detail between onlow and 
onhigh. The alternative is less relevant in the "fuzzy ranges" 
between offlow and onlow and between onhigh and offhigh, and 
it is considered too fine for levels of detail below offlow, and 
too crude for levels higher than offhigh. 

If the level of detail falls into the fuzzy range of two alterna- 
tives at once, as at level L between model,.] and model,- in Fig- 
ure 10.1, then the Tenderer has two alternatives: 

* It can choose one of the two models, ignoring the other. 

• It can "mix" the two models according to their impor- 
tance. At level L, if model/ has importance .3 and model, 
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mode! M only 


modeljonly 
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always present -- 

relative 
importance 

always absent 

or.high^ 
off low 
offhigh ( .-j = onlow 
onhighj= offlow 
offhigh j= onlow 



level of 
detail 


Figure 10.1 Levels of detail for alternative representations of a model. The hori- 
zontal axis shoxvs level of detail and the vertical axis shows the relative impor- 
tance of the alternative models at each level of detail 


has importance .4, a Tenderer could present them in that 
proportion. 

RenderMan does not dictate any one of these choices, or de- 
fine "mix" in the last choice. Its purpose is only to specify how 
different models are associated with different levels of detail. 

An example 

Listing 10.1 shows a routine using level of detail. It uses a hy- 
pothetical routine, DomeQ, which declares a geodesic dome, a 
polygonal approximation of a sphere of a given granularity. 
The higher the value of the parameter to DomeQ, the more 
polygons go into the approximation. The routine DomesQ de- 
clares several alternative domes, each with its own level-of- 
detail range. 

DomesQ first declares the bounding box of the dome, which 
we know from the hypothetical definition of DomeQ to be a 
unit cube. The level of detail of the dome is a function of the 
unit cube in image space as it is projected onto the image. 


A 

DomesO: render a geodesic dome divided according to level of detail . 
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RtBound bound; 

bound[0J = bound[2] = bound[4] = -1.0; 
bound[l] a bound(3] = bound[5] = 1.0; 

RiAttributeBeginO; /* Push attributes to save level of detail */ 
RiDetaiK bound ); 

RiDetailRange( 0.0, 0.0, 10.0, 20.0 ); 

Dome(4); 

RiDetailRange( 10.0, 20.0, 40.0, 80.0 ); 

Dome{8); 

RiDetailRange{ 40.0, 80.0, 160.0, 320.0 ); 

Domed 6); 

RiDetailRange( 160.0, 320.0, RIJN FIN ITY, RIJN FIN IT Y ); 
Dome(32); 

RiAttributeEndO; 


Listing 10.1 Routine specifying geodesic domes with different granularities 


Smooth transition between alternatives 

The fuzzy ranges of alternatives can be used to provide a 
smooth transition from one alternative to another as a scene 
changes during an animation. If the model looms larger as a 
sequence proceeds, then it makes sense to switch gradually 
from one representation to another one with a higher level of 
detail. Declaring the various alternatives with overlapping 
fuzzy ranges can ensure that result if the Tenderer supports 
this kind of continuous segue. 

Such a transition works best in the situation of model,- and 
model, + 2 in Figure 10.1. As level of detail increases, model, be- 
gins to decline in importance just as model, becomes rele- 
vant, and the former switches off just as the latter is switching 
full on. In general, for the ith and (i+l)th alternatives, it is a 
good idea to have 

offlow. +1 = onhigh ( . 

and 


onlow ; . +1 


= offhigh ; .. 


Level of Detail Calculations and Models 


199 


RenderMan guarantees the level of detail facility to work con- 
sistently only when the level of importance of all alternatives 
sums to 1 at every level of detail. The condition above meets 
this criterion if, for N alternatives, 

onloW] = 0 

and 

onhigh w =RIJNFINITY. 

This property, which is obeyed in DomesQ , provides a well-de- 
fined choice under all selection schemes. If a model's level of 
detail is such that the total importance is not 1, then the result 
is undefined. 

A simple special effect 

A good set of alternative representations, together with the 
relative level-of-detail facility, can produce an intriguing spe- 
cial effect even at a fixed absolute level of detail. Listing 10.2 
shows a program fragment for fading from one representa- 
tion to another. The geodesic dome from Listing 10.1 is 
viewed at the same size in every frame, but the relative level 
of detail increases from frame to frame. In the first frame, it is 
very small and the dome is crude, but in the last frame the rel- 
ative level of detail is 1, and the dome is seen in its full com- 
plexity. 


A 

' The following program fragment generates a series of frames 

* dissolving from a crude geodesic dome to a more detailed one 

* of the same size. 

V 

... /* Statements here set up the viewing transform for the dome */ 
for( i = 1 ; i <= N FRAMES; i++ ) 1 

... A Statements here initialize a new image V 
RiFrameBegin(i); 

RiRelativeDetaiK ((float)i)/NFRAMES ); 
RiWorldBegin(); 

DomesO; 

RiWorldEndO; 

RiFrameEndO; 

1 


Listing 10.2 Program to dissolve a crude model into a refined one 
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Procedural Models 

A procedural model declares a model not as a series of surfac- 
es like polygons and quadrics, but as a procedure that is called 
to define the model during rendering. The procedure is usual- 
ly called when the portion of the image then being rendered 
includes the on-screen projection of the model's bounding 
box. Using a procedural model can save on the cost of storing 
the model, as well as give the procedure an opportunity to 
generate the model with a complexity appropriate to the situa- 
tion. Procedural models generally have a much smaller exter- 
nal representation than the data that is ultimately rendered. 
This data amplification of procedural models can save a great 
deal of storage space, and also makes them much easier for a 
user to manipulate. 

Declaring a procedural model 

A procedural model is passed to the interface as four ele- 
ments: the data the procedure will use, a bounding box for the 
model, a pointer to a procedure for the interface to call to re- 
fine the model (the refinement procedure), and a second pro- 
cedure pointer for disposing of the data. The refinement pro- 
cedure uses the data in further describing the model. The Ten- 
derer may use the bounding box to calculate the primitive's 
level of detail and to determine when to call the refinement 
procedure. 


RiProcedural( data, bound, retineproc, t'reeproc ) 

RtPointer data; 

RtBound bound; 

RtFunc refineproc, rreeproc; 

RiProceduralO declares a single procedural model, data is a 
pointer to a block of data, bound is the bounding box of the 
model in object space, refineproci) is the refinement proce- 
dure called to express the model using RenderMan function 
calls; it may even define the model as a series of other proce- 
dural models, freeproci ) is a function called when the data is 
no longer needed. 
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The data to which data points remains owned by the applica- 
tion. The Tenderer is forbidden to do anything with it except 
use it as a parameter to refine prod) or freeprod). However, 
some Tenderers may recreate a procedural model several 
times by passing refineprod ) that same pointer. Consequently, 
neither refineprod) nor the application should modify it in a 
way that changes the resulting model. It is passed once, at 
most, to freeprod)- which is the application's only opportuni- 
ty to dispose of the associated data. Only freeprod) is allowed to 
free up the data. 

bound must completely enclose the model because it repre- 
sents a promise to the Tenderer that the model is confined to 
that region of object space. If the model touches a pixel then 
so must the bound. 


The refinement procedure 

The refineprod) procedure is called by the Tenderer when the 
model is needed for the rendering process. When refineprod) 
is called, the graphics state is the same as during the original 
call to RiProcedural(). Thus, any attributes extant when RiPro- 
ceduraK) was called will apply to any object created by refine- 
prod)- 

Depending on the implementation, refineprod) may be called 
before RiProceduralO returns. The application should make 
sure that this does not affect the resulting model. 

refineprod) is called as if it were declared thus: 

refineproc( data, levelofdetail ) 

RtPointer data; 

RtFloat levelofdetail; 

data is the value passed to RiProceduralO, and levelofdetail is 
the level of detail of the model as determined from the 
bounding box originally passed to RiProceduralO. The graphics 
environment is restored to its state as of the original RiProce- 
duralO call, except that the current level of detail is set to lev - 
elofdetaiL If levelofdetail is RIJNF1NITY, the model should be 
subdivided to the maximum possible extent. This is an impor- 
tant case to handle correctly, because if a Tenderer does not 
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Figure 10.2 How a fractal triangle is subdivided. The left shows the process of 
subdividing the edges of one triangle, the right its result. 


support procedural models it may simply call refineprocO 
once with levelofdetail set to RIJNFINITY. 

A caveat 

Unlike other pointers passed to the RenderMan Interface, no 
effort is made to copy or otherwise protect the data supplied 
by the data pointer. The pointer is simply passed back across 
the interface as a parameter to the model's refineprocO. The in- 
terface does nothing to affect the data except call freeprocO. 
However, the data is not protected from corruption by the ap- 
plication. 

Example: a simple fractal generator 

Listing 10.3 shows an example of a procedural model, a sim- 
ple fractal generator. A triangle can be rendered as a fractal by 
recursive subdivision: each edge is bisected and the midpoint 
perturbed vertically by a random amount. The original trian- 
gle vertices and the three new vertices form four triangles. 
The process, shown in Figure 10.2, ends when the resulting 
triangles are sufficiently small, as judged by their level of de- 
tail. 
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A FractaiO: procedural model for a fractal triangle. If the triangle's level of 

* detail is below a threshold, or the triangle has been subdivided more 
~ than a certain number of levels, it is presented directly as a 

M triangle ; otherwise it is divided into four smaller triangles 

V 

#include <ri.h> 

A A fractal point is a location plus a random-number seed */ 
tvpedef struct t'ractalpoint j 
RtPoint location; 
in! seed; 

} FractalPoint; 

A A fractal triangle is three vertices and a level number used 

* to limit subdivision V 
typedef struct fractaltriangle 1 

FractalPoint vertices[3] ; 
int level; 

] FractalTriangle; 

^define MOVEPT(src,dst) ldstf0)=src[0); dstjl 3—srcIl ]; dst[2j=src[2]; ) 

A FractalDivQ: RenderMan refinement procedure for subdividing a fractal 
' triangle. V 

FractalDiv( data, levelofdetai! ) 

RtPointer data; 

RtFloat levelofdetai); 

\ 

FraaalTriangle *pTriangle = (FractalTriangle “)data, "pChild; 

RtPoint vertices|3); 

it (levelofdetai Id .0 II pTriangle->leveI>MAXLEVELS ) ( 

A Small enough to be rendered V 
MOVEPT(pTriangle->vertices|0). location, vertices|0]); 

MOVEPT (pTriangie->vertices[ 1 ] .location, vertices [ 1 )); 
MOVEPT(pTriangle->vertices[2). location, vertices [2]); 

RiPoIygon( 3, RI_P, (RtPointer) vertices, RI_NULL ); 

) else A Too large ; subdivide */ 

TriangleSplitf pTriangle ); 

I 

ATriangleSplitO: subdivide a FractalTriangle, giving it an array of 
' four dynamically-allocated children. */ 

T riangleSplitC pFT ) 

FraaalTriangle *pFT; 

I 

int childnum; 

RtBound bound; 

FraaalTriangle *pChildren; 

pChildren = (FractalTriangle *)malIoc{ 4*sizeof(FractalTriangle) ); 

A Give each child a level number V 
for(childnum = 0; childnum < 4; childnum++) 
pChildrenichildnum]. level = pFT->level+1 ; 
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/* Give the first three children one vertex from the parent and one 
* edge midpoint as vertices V 
fort childnum = 0; childnum < 3; childnum++ ) ( 

pChildren[childnumj.vertices[0] = pFT->vertices[chiidnum]; 
EdgeSplitt &(pFT->vertices[chi!dnum|), 

&(pFT->vertices[(childnum+1 )%3j), 

&(pChiidren [childnuml. vertices! 1|)); 





/* Give the fourth (inside) child vertices from the split edges , and give 
* the other three children their third vertex. “/ 
for( childnum = 0; childnum < 3; childnum++ ) ( 
pChildren[3|.vertices[childnum] = 

pChi!dren[(chi!dnum+l )%3|.vertices[2] = 
pChiidren [childnum]. vertices!! ]; 

I 

fort childnum = 0: childnum < 3; childnum-r^- ) ( 

/* TriangieBoundO computes the bounding box for a triangle 
TriangleBoundt pCnildren, bound ); 

RiProceduraK pChildren-r+, bound, FractalDiv, free 


#define SEEDTODISPLACEMENT(seed) (seed/((doublej(1«3't/,> 
double EdgeLent ); 



/* EdgeSplitt): split an edge between two vertices to derive a third vertex */ 
EdgeSplitt pFPI , pFP2, pFPOut ) 

FractalPoInt “pFPI, *pFP2, ‘pFPOut; 


f 


double displacement = 

SEEDTODlSPLACEMENTt (pFP1->seed + pFP2->$eed}/2); 
srandomt (pFPl->seed -r pFP2->seed)/2); 
pFPOut->seed = randomt); 

EdgeMidptt pFPl->location, pFP2->location, pFPOut->location ); 
pFPOut->location[2| += 0.25 ’ displacement “ 

EdgeLent pFPI ^location, pFP2->location ); 


/* EdgeMidptt): return the midpoint of an edge V 
EdgeMidptt ptl, pt2, midPt ) 

RtPoint ptl , pt2, midPt; 


midPtlOl = (ptl {0J-f-pt2[0])/2; 
midPtfl] = (ptl [1 J-rpt2il ])/2; 
midPt[2| = (ptl [21--pt2[2|)/2; 


/* EdgeLent): return the Euclidean length of an edge m f 
double EdgeLent ptl, pt2 ) 

RtPoint ptl, pt2; 

I 

double xde! = pt2(0)-pt1 [0], 
ydel = pt2[l j-ptl H j, 
zdel = pt2[2]-pt1 [2] ; 
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double len = sqrt( xdel*xde! + ydel*ydel + zdel*zdel ); 
return( len ); 


/“TriangleBoundO: calculate the fractal bounding box of a triangle as 
* the union of the bounding boxes of its edges */ 

TriangleBound( pFT, bound ) 

FractalTriangle “pFT; 

RtBound bound; 

I 

RtBound tmpBound; 

EdgeBoundt pFT->vertices|OJ. location, pFT->vertices[1 ]. location, bound ); 
EdgeBound{ pFT->vertices|1 ) .location, 

pFT->vertices[2]. location, tmpBound ); 

BBoxUnion( bound, tmpBound, bound ); 

EdgeBound( pFT->vertices[2]. location, 

pFT->vertices|0]. location, tmpBound ); 

BBoxUnion( bound, tmpBound, bound ); 


^define min(a,b) ((a)<{b)?(a):fb)) 

^define max(a,b) {(a)>(b)?(a):(b)) 

#define SPHEREBUMP 1 A 

/* EdgeBound: calculate the fractal bounding box of an edge , with its y 
* range expanded to allow for midpoint perturbation. V 
EdgeBound( ptl, pt2, bound ) 

RtPoint ptl , pt2; 

RtBound bound; 

I 

double radius; 

RtPoint midpt; 

bound[0] = mintptl |0], pt2(0]); boundjl) = max(pt1 10], pt2 10] ); 

bound|2) = min(ptl |1], pl2[l]); bound[3] = max(ptl [1], pt2 [ 1 ] ) ; 

EdgeMidpt( ptl , pt2, midpt ); 

radius = (EdgeLen(pt1 , pt2)/2)"SPHEREBUMP; 

bound[4] = midpt{2] - radius; boundI5] = midpt[2] + radius; 

) 

/* B Box Union; set a bound to be the union of two other bounds ’/ 
BBoxUnion{ boundl, bound2, ubound ) 

RtBound boundl, bound2, ubound; 

I 

uboundIO] = min( boundl |0], bound2[0] ); 
ubound[l ] = max( boundl (1 ], bound2[l ] ); 
ubound|2] = mint boundl [2], bound2[2] ); 
ubound|3] = max( boundl [3], bound2{3] ); 
ubound[4] = mint boundl |4], bound2[4] ); 
ubound[5] = max( boundl [5], bound2[5] ); 


Listing 10.3 A procedural fractal generator 
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Modus operandi of FractalDivO 

The data passed to FractalDivO is a pointer to a triangle, an ar- 
ray of three points. If the level of detail of the triangle is below 
a threshold, the triangle is simply declared outright as a poly- 
gon. Otherwise, the triangle is divided into smaller triangles 
as follows: each edge of the triangle is bisected, and the y coor- 
dinate of the midpoint is perturbed by a random amount. The 
resulting perturbed midpoints and the existing vertices are 
used to form four smaller triangles, one formed from the 
three midpoints and the others from two original vertices 
and one midpoint each. 

Data structures 

FractalDivO uses two data structures. A FractalPoint represents 
a triangle vertex. It consists of an RtPoint for the vertex loca- 
tion, plus a seed for random-number generation in subdivi- 
sion. The tricky thing about fractals is ensuring that coincid- 
ing edges from two triangles that abut, are divided in exactly 
the same way. The only way to do that is to make sure they 
are both divided using the same random-number seed, so 
each vertex carries the seed for one of the edges it adjoins. 

A FractalTriangle consists of three FractalPoints (its vertices) 
and a number indicating the level of subdivision this triangle 
represents. Level 0 is given to the original triangle declared to 
RiProceduralO, and it is increased by 1 in its children. The lev- 
el number is used to limit the maximum extent of subdivi- 
sion. 

Bounding-box calculation 

The only other interesting thing about this program is the 
method used to calculate the bounding box of an edge. Since 
the midpoint of the edge may potentially be perturbed above 
the upper vertex or below the lower one, the bounding box 
needs to be expanded in y. This is done here by calculating the 
edge's bounding circle in y, expanding it by the factor SPHERE- 
BUMP, then using that in the bounding box. 

Figure 10.3 depicts the results of a maximal subdivision on a 
triangle. Properly colored, it effects a remarkable rendition of 
a tortilla chip. 


Procedural Models 


207 



Figure 10.3 A fully subdivided fractal triangle 


This fractal procedure is illustrative of procedural models, but 
it could be improved in a number of ways. First, the fraction 
of edge length that limits the perturbation could be made a pa- 
rameter of the triangle. Second, to model more closely a real 
fractal, this fraction should be diminished at each subdivision 
by a factor that could also be made a parameter. Third, the 
bounding box calculation could be made tighter by an analysis 
of the maximum possible perturbation. Finally, the possibility 
exists here that, of two adjoining triangles with appropriate 
levels of detail, one could subdivide and the other not, yield- 
ing a crack. Fixing that problem would require the subdivi- 
sion criterion to apply to edges independent of triangles. 
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CHAPTER 1 1 


Lighting and Shading 


r . This chapter discusses RenderMan's facilities for ma- 
* nipulating the appearance of objects: how to create and 
position light sources, and how to color surfaces with 
something other than a flat color. Thus begins a change in em- 
phasis from geometric shape to that of shading: calculating 
the color of each surface as seen in the output image, as well 
as its shape and position. We will consider how shading 
works for a single point, a sample of the surface, under the as- 
sumption that an entire surface can be shaded as a number of 
sample points. 

Before any point on a surface can be shaded, it must be placed 
in a scene and given surface properties like color and transpar- 
ency. Light sources for illuminating the object must be speci- 
fied in terms of their color, intensity and propagation. Tne po- 
sition of the camera is also important, since many surfaces re- 
flect light differently in different directions. Given all this 
information, the color of any surface point can be calculated. 

RenderMan summarizes all those influences as a model of a 
specific physical process. This shading pipeline is illustrated 
in Figure 11.1. For each visible point on a surface, shading it 
involves the following: 

• Illumination: determining the intensity and color of light, 
from various light sources and even other surfaces, that 
arrives at this point. 

• Reflect! on /Transmission: simulating the interaction of 
the arriving light with the material making up the sur- 
face. The simulation calculates the intensity and color of 

J 
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Figure 11.1 Three basic parts of the shading process: emission at the light 
source, interaction of the light with the surface, and atmospheric effects between 
the surface and the viewpoint 


the light reflected from the surface toward the viewer or 
in a particular direction of interest. 

• Atmospheric effects: modification of the light's color as it 
travels from the object to the viewer, perhaps by particles 
in the atmosphere. 

Rendering systems generally implement these processes as 
one monolithic shading process that proffers a large array of 
parameters. The RenderMan Interface, on the other hand, de- 
fines each of the tasks above as a shader: there are light 
source shaders, surface shaders, volume shaders, and others. 
Each shader is a programmed procedure, written in the Ren- 
derMan Shading Language, wdiich embodies one of those pro- 
cesses individually. 

While the physical model is fixed, the shading calculation is 
controlled in part by the selection of a shader for each task. A 
variety of standard shaders is a part of the definition of the 
RenderMan Interface: there are point light sources, distant 
light sources and spotlights, for example. An application 
■would invoke a point light source or a distant light source by 
an appropriate selection of shader. Even a single shader (for 
example, a distant light source) can be made to exhibit differ- 
ent characteristics by manipulating its parameters for things 
like color, intensity and direction. 
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The main purpose of this chapter is to introduce shader selec- 
tion and control, and present the standard shaders. But the 
possibilities of the shading process are not limited to the stan- 
dard choices shown here. Spedal-purpose light sources are 
easy to imagine, for example. There are also important trade- 
offs to be made between shading accuracy and computational 
expense. Much of the justification for a rendering structure 
that incorporates shaders is to allow users to define their own. 
This is an exciting area that is discussed in depth in the final 
four chapters of this book. 


Using Shaders 

A shader is a procedure called to compute a value or set of 
values needed during rendering. For example, a light source 
shader is called when the direction and color of light sent by 
the light source to a particular point on a surface is needed. 
The shader -for a light source uses as input the direction to- 
ward the surface point, the light's color, direction, and so on. 

Shaders as procedures 

Shaders are procedures written in the RenderMan Shading 
Language, and they usually exist as autonomous modules in- 
voked by a Tenderer at runtime. The routine that adds a light 
source to a scene is just a directive to access a named shader. 

Shader instances 

One important distinction between shaders and normal proce- 
dures is that there are commonly several "flavors," or in- 
stances, of a given shader in use at once. Instances of a single 
shader vary not in functionality but in their parameters. In 
this respect, shaders resemble classes in an object-oriented pro- 
gramming paradigm, with instances corresponding to objects. 
For example, there may be several point light sources in a 
scene (several instances of the "pointlight" shader), each with a 
different color, intensity and position. Similarly, while a giv- 
en surface is always shaded by the same surface shader, differ- 
ent surfaces may use distinct instances of the same shader just 
as easily as they could use different shaders altogether. 
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The shader used for a given shading task may be an attribute 
(part of the graphics environment just like surface color) or 
an option, depending on its type. There is a current instance 
of a surface shader that is attached to each object as it is de- 
clared, a current atmosphere volume shader, and so on. For 
each type of shader (light source, surface, atmosphere, etc.) 
there is a RenderMan routine to declare its current instance. 

The information distinguishing one instance from another 
takes the form of procedure parameters known as instance 
variables. Values are bound to the instance variables of a 
shader when the shader is entered into the graphics environ- 
ment. They are passed to the interface routine declaring the 
shader in a parameterlist of token-value pairs: RiLightSourceQ, 
for example, adds a light source shader, taking the color, inten- 
sity and position of the light source in its parameterlist. These 
assign values to the instance variables of the shader. Assign- 
ment to instance variables is optional; default values for each 
unassigned instance variable are provided by the shader. 

It may be useful to think of a shader instance as an object bun- 
dling the functionality of the shading procedure with values 
for the instance variables used by the procedure. 

Uniform vs. varying instance variables 

Instance variables are usually uniform: ever } 7 time the shader 
is invoked by the Tenderer, they have the value that was giv- 
en them when the shader was instanced. However, there is 
an alternative: the value of a varying instance variable can 
change systematically. Varying instance variables are most 
commonly used for interpolated surface parameters. If the pa- 
rameterlist of a geometric primitive declaration includes a ver- 
tex variable with the same name as an instance variable of the 
current surface shader, then that is used for the instance vari- 
able. The value is interpolated to each point on the surface, 
and the shader will have the interpolated value when it is 
called. For example, a visualization process might bind a tem- 
perature value, temp, to the vertices of a polygon; if its surface 
shader uses a temp instance variable, it will receive the inter- 
polated temperature at interior points. 

This ability to interpolate arbitrary parameters is a powerful 
feature of RenderMan. It allows the information influencing 
the appearance of an object to be completely unconstrained. 

212 Chapter 11 : Lighting and Shading 




Environment variables used by shaders 

In addition to their instance variables, shaders may use cer- 
tain elements of the graphics environment. In Chapter 2, we 
first encountered the RenderMan procedure for setting the re- 
flectiveness of the surface as a color. 


RiColort Cs ) 

RtColor Cs; 

RiColorO replaces the current surface color in the graphics en- 
vironment with the new color Cs. The current color is an at- 
tribute of the graphics environment, saved and restored like 
any other. 

If a surface color "Cs" (RI_CS) is declared in the parameterlist of 
a geometric primitive, it overrides that declared with RrCol- 
or(), but only for that particular primitive. 


When a surface is declared, it is assigned the current color in 
the graphics environment. Shaders generally use the surface 
color to compute the color of light reflecting from the surface 
toward the eye. They may also use the current opacity. 


RiOpacityt Os ) 

RtCoior Os ; 

RiOpacityO changes the current surface opacity in the graphics 
environment. Os is a color giving the proportion of each col- 
or channel that the surface absorbs in passing light through it. 
A completely transparent surface has opacity 0 in all channels, 
a completely opaque surface opacity 1. A colored filter would 
have different values in each channel. 


Both color and opacity may be made uniform (constant over a 
surface), by using the above routines, or varying (bound to 
vertices and interpolated), by use of vertex variables. This is a 
special case, provided because surface color is a particularly 
importartt attribute. In general, the instance variables of a 
shader are declared to be either uniform or varying. 
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Shading attributes 

We mentioned earlier that a surface is shaded by calculating 
its appearance at a number of points and using those values 
for other points. If this frequency of shading (the shading 
rate) is large compared to the number of pixels touched by the 
surface (and uniformly distributed across the surface), the re- 
sulting image will be able to depict rapid changes in appear- 
ance across the surface. On the other hand, a surface with a 
smooth, slowly changing shade may be perfectly well ren- 
dered with far less frequent shading. In either case, an applica- 
tion might use relatively infrequent shading in the early stag- 
es of developing an image ("draft mode") and more frequent 
shading for final rendering. In neither case can the Tenderer 
determine a priori how rapid a shading rate is "good enough." 

The shading rate sounds very reminiscent of the sampling 
rate discussed in the last chapter, but RenderMan assumes 
that the frequency' with which the shade of a surface is calculat- 
ed is independent of sampling rate. The latter might be more 
frequent because the configuration of surfaces in a scene can 
easily change much more rapidly than the color of any one 
surface, or \ice versa. The shading rate concerns how fre- 
quently a given surface is shaded. The sampling rate addresses 
the sampling of the scene as a whole. The two are not neces- 
sarily related. 

RenderMan allows control over shading rate in two ways. 
First, it may be declared as an area (measured in pixels) per 
sample. Second, the application may determine whether the 
shade between samples is interpolated or not. 


RiShadingRatef size ) 

RtFloat size; 

RiShadingRateO controls the frequency of shading a surface. 
size is specified as an area in pixels: if size is 1, a surface is 
shaded about once per pixel. Large values of size cause cruder 
but faster shading. 

The shading rate is an attribute of the graphics environment. 
It can vary for each surface, and is saved and restored with the 
rest of the graphics environment. 
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The ability to vary the shading rate, intelligently used, can be 
a powerful tool for optimizing the trade-off between appear- 
ance and rendering speed. 

Shading interpolation 

The shading rate determines how frequently the appearance 
of a surface is fully calculated. The next routine determines 
how to depict other points on the surface in terms of nearby 
samples. 


RiShadinglnterpoiationi type ) 

RtToken type; 

type should be either "constant" (RI_CONSTANT) or "smooth" 
(RI_SMOOTH). If the former, points on the surface between 
samples take the shade of the nearest calculated sample. If the 
latter, other points are interpolated from neighboring samples 
so that the appearance varies smoothly. 


Constant shading is most useful when the shading rate is on 
the order of a pixel (and the in-between points are not re- 
solved), when a surface changes relatively little from point to 
point, or when relatively coarse shading is "good enough." 
Smooth shading is more appropriate when a large shading 
rate causes abrupt transitions between samples that can be 
seen in the output image. 

So-called Gouraud shading is a special case of sampling and 
interpolation: the surface shade is calculated at polygon verti- 
ces and interpolated for points in the interior. 

When the shading rate is set to a value larger than any poly- 
gon and the type of shading interpolation is "smooth”, Gou- 
raud shading results. The shade is calculated for polygons at 
their vertices and smoothly interpolated across their interiors. 

A special kind of shading 

A very special-purpose option for shading suppresses the en- 
tire shading process. In motion-picture work, it is often useful 
to use objects to describe holes in an output image so the im- 
age can later be merged with other information. An object 
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used this way is said to function as a matte object (a three-di- 
mensional equivalent of what is commonly called a hold-out 
matte). RenderMan allows an object to be used as a matte ob- 
ject by calling RiMatteO. 


RiMattef ) 

RiMatteO causes each subsequent object to act as a matte object, 
i.e., to be rendered without shading but with objects behind 
them hidden. The areas where a matte object appear in an im- 
age are rendered black and transparent, regardless of what lies 
behind it. RiMatteO controls an attribute in the graphics state, 
so its effect is cancelled the next time the state is restored. 


Light Source Shaders 

The first class of shaders are the light source shaders, which 
calculate the intensity and color of light sent by the light 
source to a point on a surface. Figure 11.2 shows the basic idea. 


RtLightHandle RiLigbtSourcei name, parameterlist ) 
char ‘name; 

RiLightSourceO adds a new light to a scene by creating an in- 
stance of the shader identified by name. The standard light 
source shaders defined under the RenderMan Interface are de- 
scribed below, parameterlist is a series of token-value pairs giv- 
ing the instance variables of the shader. The relevant token- 
value pairs for each standard shader are listed with it. Any in- 
stance variables declared in parameterlist but not used by the 
shader are ignored. The value returned by RiLightSourceO is a 
handle that may be used later to turn the light on and off. 
Lights are on when they are created. 

There is no defined limit on the number of light sources, but 
individual implementations may have their own limitations. 


Light source shaders are the only shaders that may have mul- 
tiple instances available at the same time. That is, when a 
light source is instanced by RiLightSourceO, it does not replace 
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Figure 11.2 The purpose of a light source shader 


any existing light source, but is added to the light list. Once a 
light source is created, it remains defined until the end of the 
enclosing frame or world block. That is, if a light source is cre- 
ated before RiWorldBeginO, it still exists after the correspond- 
ing RiWorldEndO, and similarly for RiFrameBeginO and Ri- 
FrameEndO. This mechanism allows exactly the right set of 
light sources to persist from frame to frame of an animation, 
for example. 

Switching a light on 

Since light sources remain once they are created, RenderMan 
provides the ability to turn them on and off individually. Sur- 
faces are illuminated by each light source that is on when they 
are created. 


Rillluminate{ light, onoff ) 

RtLightHandle light; 

RtBoolean onoff; 

RillluminateO turns a light on or off. light is a light source han- 
dle as returned by RiLightSourceQ. If onoff is RI_TRUE, the light 
source is turned on; if RI_FALSE, the light is switched off. 
Light sources are on by default. 

The state of each light source is part of the graphics environ- 
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ment. Therefore, restoring the graphics state can turn lights 
on or off without a call to RillluminateO. 


The list of light sources is maintained outside of the graphics 
state. The state of each light, on the other hand, is part of the 
graphics state. Conceptually, a light is off before it is created. 
As a result, restoring an environment that was saved before a 
light source was created will not destroy the light source, but 
only turn it off. Therefore, exactly the same set of lights is on af- 
ter an attribute block as before it. Other sources created inside the 
block may be turned on. 

Predefined light sources 

The set of light source shaders predefined by the RenderMan 
Interface is explained below. They are available regardless of 
whether the implementation supports the RenderMan Shad- 
ing Language. Figure 11.3 demonstrates them in action; List- 
ing 11.1 gives the program used to produce those four images. 

Default light source 

Since light sources can only be added to the scene, not deleted, 
there is no default light source. The examples of earlier chapters 
either declared a light source explicitly, or used a constant sur- 
face shader, which requires no light source. 

Ambient 

RiLightSource; "ambientlighf, 

"intensity' 1 , intensity, 

“lightcolor 1 ', color, 

Ri_NULl) 

RtFloat ‘intensity; 

RtColor color; 

An ambient light source distributes light uniformly through- 
out space in all directions. Therefore it throws the same light 
on every surface regardless of the surface's position or orienta- 
tion. Most scenes include a small ambient light source to pre- 
vent any surface from being completely unilluminated. 
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ambient light 


spotlight 

Figure 11.3 Four basic light sources illuminating a basic scene 


The declaration of an ambient light source may optionally in- 
clude the intensity and color of the source. If not supplied, the 
intensity is set to 1 and the color to maximum white (1 in all 
components). 

Distant light 

RiLightSource{ “distant! ight", 

"intensity”, intensity, 

"lightcoior”, color, 

"from”, from, 

“to", to, R1JMULL ) 


distant light 


point light 
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RtPoint from, to; 

RtFioat intensity coneoeltaangle, coneangle; 
fromjOi = from[1] = from!2] = 

to[0]«...: to [ 1 ; = . . . ; to[2) = 

intensity = 

RiFrameBegin 

RiLightSource" ; amb!enti!ght^ 

(RtToken' B intensity* ! , (RtPointer)&intensit> 

RLNULL»; 

RiWorldBegin 

RiWorldEnd 

RiFrameEnd 


RiFrameBegin .'2 

RiLightSource" distant iight", 
(RtToken' ,! intensitv' , 
fRfToken'“from' , 
(RtToken u *to' 
RLNULL’; 
RiWorldBegin 

RiWoridEnc 

RiFrameEnd 


(RtPointer)& intensity , 

(RtPointer)trom, 

(RtPointer)to, 


RiFrameBegin 3 

RiLightSource'’pointiight' 

fRtToken ‘-intensity (RtPointerj&iniensity, 

(RtT oken ‘“from' , (RtPointer)from, 

RLNULL ; 

RiWorldBegin 

RiWorldEnd 

RiFrameEnd;,- 


RiFrameBegin.^ 

RiLightSource' l spotiight ,, ) 

(RtT oken^'intensiTy 1 ', fRtPoinler)kintensity, 

fRtToken Vronedeltaangle'', fRtPointeo&conedeiiaangle. 
(RtToken'“coneangie'\ (RtPointer)&coneangle, 

(RtToken^Trom", (RtPointer)from, 

(RtT oken'"to", (RtPointer)to, 

RLNULL); 

RiWorldBeginO; 

RiWorldEndO; 

RiFrameEnd (); 


Listing 11.1 Program invoking four basic light sources 
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RtFloat “intensity: 

RtColor color; 

RtPoint from, ter 

The light of a distant light source flows uniformly in space 
in one direction. As a result, surfaces of like orientation re- 
ceive the same amount of light independent of location. How- 
ever, surfaces of different orientation are illuminated different- 
ly. Those facing directly toward the light source appear bright- 
est and those facing away are completely unilluminated. 

The best-known example of a distant light source is the sun. 
As viewed from the earth its rays are essentially parallel and 
position makes no practical difference in its intensity. 

The two RtPoint parameters to and from give the direction of 
the source. It faces along the vector {from- to). The default from 
is (0, 0, 0) and to is (0, 0, 1 ). If the distant light is declared in 
camera space, this yields a direction straight along the positive 
r axis, illuminating all surfaces visible from the viewpoint. 
The defaults for 'ntensitv and color are 1.0 and white, as with 
ambient sources. 

Point sources 

RiLightSourcei "pointlight", 

"intensity"; intensitv, 

"lightcoior". coior, 

“from . 11 from.RLNULLj 

RtFloat *intensit\ ; 

RtColor color: 

RtPoint from; 

A point light source distributes light through space from a 
single point. It shines evenly in all directions, but the intensi- 
ty of the light falls off with the square of the distance from the 
light to the surface. 

The location of a point light source is given by the RtPoint 
from parameter, which is (0, 0, 0) by default. Any explicit from 
positions are in the object space of the light source declara- 
tion. As before, intensity gives the intensity of the source, 
which is 1.0 by default. 
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Spotlight 

RiLightSource "spotlight", 

"intensity", intensity, 

"lightcolor", color, 

“from", from, 

“to", to, 

"coneangle", coneangle, 

"conedeltaangle", conedeltaangle, 

"beamdistribution", beamdistribution, RI_N”JLL 
RtFloat "intensity: 

RtColor color; 

RtPoint from, to; 

RtFloat "coneangle, "conedeltaangle, *beamdistribution ; 

A spotlight is a light source with both position and direction. 
It simulates a cone of light emitted from one point from to- 
ward another point to. The intensity of the emitted light falls 
off exponential]} - with angle from the center of the cone. 

The first four instance variables of a spotlight have the same 
meaning as those of point and distant sources. A spotlight has 
a falloff with angle F CO neangie from the spotlight direction to 
the direction of the surface point. F CO neangle is controlled by 
the last three instance variables. It decays from 1 in the spot- 
light direction ( from-to ) to 0 coneangle radians away, and so is 
nonzero only inside a cone 2 *coneangle radians wide. The ex- 
ponent of decay is given by beamdistribution: larger values 
give a narrower light source, smaller values a wider one. 

Formally, Fconeangie is the product of two decay functions F\ 
and Fn. If L is the direction from the surface point to the spot- 
light, and A is the direction in which the light source points, 
then F] is 

p _ (L, ^beamdistribution 

which is 1 for points in the direction of the spotlight, decaying 
geometrically with the cosine of the angle between L and A. It 
is 0 for points 90 degrees off-center. More precisely, it is the co- 
sine of the angle of the point with respect to the spotlight di- 
rection, raised to the power beamdistribution. 

The second angular falloff, F 2 , is given by a smooth, continu- 
ous function that is 1 from , the spotlight direction to 
( coneangle-conedeltaangle ) radians away and 0 for points 
more than coneangle degrees from the spotlight direction. 
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Figure 11.4 Geometry of spotlight calculation 


with a smooth falloff in between. This function provides a 
penumbra-like decay, which helps prevent aliasing at the edg- 
es of the spot. 

Figure 11.4 illustrates L and A. Figure 11.5 plots F\, F 2 and 
Fdist as a function of the angle between L and A for the values 
of coneangle, conedeitaangle, and beamdistribution used in 
Listing 11.1. 

Positioning light sources 

The positional and directional coordinates of light sources are 
treated like those of any geometric object. The position and di- 
rection are transformed by the current transformation as de- 
fined when the light source is declared. This allows a great 
deal of flexibility in placing light sources. If a positional source 
is declared after RiProjectionO but before the camera transfor- 
mation, it is in camera space and fixed relative to the view- 
point. If it is declared after RiWorldBeginO but before any trans- 
formations, its points are in world space. Inside the world 
block, a light can be attached to an object by simply declaring it 
next to the object. All of these can be very handy in animating 
scenes with moving light sources. 
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In a sense, the from and to parameters of the spot, point and 
distant sources ere redundant because all are defined to lie at 
the coordinate origin pointing along the positive r axis in ob- 
iect space. A liept can be positioned or pointed just as well by 
using a modeling transformation to position and point the 
light's object coordinate system. In fact, this is a good practice 
because light source shaders that do not use from instance 
variables are more widely applicable, since they may be used 
in the area light sources described next. The standard shaders 
above use those variables because they make it easier to set up 
lights using an explicit position and direction. 

Area light sources 




» 

j 


One of the traditional limitations on the realism of synthetic 
imagery is the non-physical character of many types of light 
source: a point light is infinitesimal in size, so it casts a harsh 
light. Almost any real source emits light over some area in 
space. Two examples are frosted glass light bulbs and fluores- 
cent tubes. 

The RenderMan Interface provides the capability to describe 
such area light sources, although Tenderers are not required 
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to support them. The basic procedure is to instance the light 
source shader, then declare a series of geometric surface primi- 
tives. All primitives declared before the next call to RiAttri- 
buteEndO will be added to the area light. 


RtLightHandle RiAreaLightSource name, parameterlist) 
char 'name; 

As before, name is the name of the shader to be applied to the 
area light. In general, any light source shader that does not 
have a “from" positional instance variable may be applied to 
an area light. 

From RiAreaLightSourceO up to the next restoration of the 
graphics environment, usually by RiAttributeEndO, any sur- 
face primitive that is declared will be added to the area light. 

Area light sources are added to the set of current light sources 
and subsequently treated exactly as any other light source. 


Surface shaders 

A surface shader is called to determine the color of light re- 
flecting from a point on a surface in a particular direction. 
Usually this happens when the point is found to be visible. 
Most surface shaders use the light arriving at the surface (as 
obtained from a light source shader) and the nature of the sur- 
face itself to calculate the color and intensity of the reflected 
light, but shaders may be written to use any other informa- 
tion deemed appropriate. 

A surface shader also has the opportunity to set the opacity of 
the surface at the point. With the cooperation of the Tenderer, 
the shader can thus let a surface reveal, either partially or 
completely, the surfaces behind it. 

The character of the surface is embodied partly in the defini- 
tion of the shader and partly in the shader's instance vari- 
ables. For example, there is a shader defined by the interface 
for a specular (shiny) surface. However, the shininess of a par- 
ticular surface is given by an instance variable of the specular 
shader. 
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Elements of Surface shading 

e the light emerging from a surface, surface 
se any or all of the following information: 

the direction, color and intensity of the arriving light. 

the surface, as given by RiColorO or assigned to 
of the surface when it was defined. 


To character^ 
shaders mav 


the color of 
the vertices 


the opacity 
absorbs li 
a color to 
la ted. 


the orientation of the surface, as given by the surface nor- 
mal vector. The actual geometric normal may differ from 
the shading normal, which is a fiction used solely for shad- 


ing. 

the direct: 
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different 
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The last two 
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The geometric 
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coincide, then 
reaches the ca: 


• of the surface, the extent to which the surface 
ht coming from behind. Opacity is expressed as 
RiOpacityO or assigned to vertices and interpo- 


ijon in which the surface is viewed, the incident 
Mirrorlike surface reflections (highlights) are 
ecular surfaces when the camera lies in the mir- 
n from the light. For other surfaces, the color re- 
y depend in part on the incident vector. Though 
ang a surface may be scattered arbitrarily in many 
directions, the surface shader is concerned only 
ght leaving the surface along the incident vec- 


factors above, so-called geometric factors, are cal- 
rendering system and provided for the shader 
by the application. 

factors 1, L and N are illustrated in Figure 11.6 
"halfway vector" H, which points halfway 1 be- 
vector L and the incident vector I. If H and N 
a mirror reflection of the light from the surface 
mera. 


it 


Color of reflections 

Light arriving at a surface is described as a color. Computer 
graphics systems typically express the color of light as a triple 
giving the proportions of red, green, and blue in the light, al- 
though RiColofSamplesO can be used to change this character- 
istic. When red, green, and blue, for instance, are mixed in the 
specified proportion, the result will be the specified color. 
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Figure 11.6 Geometric factor s in surface reflection 


The surface color is expressed as a similar triple, but one giving 
the reflectivity of the surface by three values between 0 and 1, 
each giving the proportion of red, green, or blue that the sur- 
face reflects: 

red reflected - redinciaent * red reflectivity 
green reflected = grsen mc ident * green reflectivity 
blue reflected = blue incident * blue reflectivity 

Thus, white light (with red=green=blue= 1) striking a surface re- 
flects in the surface color. 

If the reflectivity of a surface is less then 0, negative amounts 
of light will be reflected from the surface. If it exceeds 1, more 
light reflects from the surface than strikes it. Both these cases 
are clearly non-physical. Light sources, on the other hand, fre- 
quently have much larger values than 1 because intensity can 
have any finite value. Generally, the intensity of light arriv- 
ing at the eye — the product of light intensity and reflectivity 
in each color — should fall between 0 and the value one passed 
to RiQuantizeO. This ensures that the output of the Tenderer 
will not fall outside the range of representable values. 

Types of reflection 

The predefined surface shaders treat reflected color as a 
weighted sum of three components: ambient, diffuse, and 
specular reflections. The principal difference between the 
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RtFloat ka, kd, ks; 
RirrameBeginf] ; 
RiWoridBegin'j; 

kd = 1 ; ka i ks = 0; 
RiSurface "piastic’. 


(RtToken) ,, Ka , \ 

(RtTokenVKd", 

(RlToken)"Ks\ 

RLNULL); 


RiWoridEnd ;; 
RiFrameEndj 
RiFrameBegtn:2 >; 
RiWoridBegin 

ks = 0.5; Kc = kd = 0; 


RiSurface ’piasti 


RiWoridEnd 
RiFrameEndO; 

RiFrameBegin;3r 
RiWorldBeginO 

ka = G.3 : ks L kd = 0; 


fRtToken)"ka", 

(RtToken^Kd", 

(RtTokenV’Ks", 

RLNULL); 


RiSurface oiastic' 


RiWoridEnd 
RiFrameEnd(j; 
RiFrameBegim4;; 
RiWoridBesinQ; 

ka = 0.5; 
ks = 2 ; 
kd = 0.5; 

RiSurface ' p astic’, 


(RtTokenV'Ka 11 , 

(RtTokenV'Kd", 

(RtToken)"Ks", 

RLNULL); 


RiWorldEndO; 

RiFrameEndQ; 


(RtTokenV'Ka", 

(RtTokenV'Kd", 

(RtTokenVKs", 

RLNULL); 


(RtPointen&ka 

{RtPointer)&kc 

(RtPointer)<Srks 


(RtPointer)<S-Kc 

(RtPointen&'kc 

(RtPointen&ics. 


(RtPointen&'Ka. 

fRtPointer)«SKC 

iRtPointer)<Ski 


(RtPointer)kka, 

(RtPointer)&kc, 

(RtPointer)kks, 


Listing 11.2 Ambient, diffuse and specular reflections , and c summation of all 
three 
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shaders is in how they handle those three components, the 
weight they give to each. 

Figure 11.7 illustrates the different effects of these three com- 
ponents. It was generated by the program like the one in List- 
ing 11.2. 



Figure 11.7 Appearance of ambient, diffuse, and specular reflections, and a 
scene summing all of them . The top uses an ambient light source, the middle two 
a distant source and a spotlight, and the bottom all three. 
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Ambient reflection 

.Ambient reflection is the name given to surface reflection of 
ambient light sources. The intensity of the reflection is inde- 
pendent of both surface location and orientation, but its color 
is affected by both the color of the light source and the reflec- 
tivity of the surface. The top of Figure 11.7 shows that ambi- 
ent reflection is completely flat. 

Diffuse reflection 

If a surface scatters light uniformly, the surface appears equal- 
ly bright from all points of view. The intensity of light striking 
the surface, on the other hand, is proportional to the area the 
surface presents to the light source. Thus diffuse reflection is 
brightest for a light source directly above the surface; a light 
near the surface's "horizon" lights it obliquely, hence dimly; 
below the horizon, no light at all reaches the surface. 

The second image in Figure 11.7 shows how the diffuse com- 
ponent of reflection affects the appearance of a surface under a 
distant light source: the apparent brightness of the surface var- 
ies only with the orientation of the surface. 

Formally, thej color of the diffuse reflection is that of the inci- 
dent light scaled by the cosine of the angle between the surface 
normal and the incident direction. If Cl is the color of the inci- 
dent light, N the surface normal vector, and L the direction to 
the light source, then the reflected intensity’ is 

C] = Cl* max(0,N • L) 

Specular reflection 

Specular reflection is the mirrorlike reflection of a surface at 
or near the mirror direction, the light source direction reflect- 
ed about the surface normal. If the camera lies in the mirror 
direction, a specular reflection appears very’ bright. For a per- 
fect mirror, only viewpoints in the mirror direction receive 
any specular reflection at all. 

Few surfaces are perfect mirrors, but many’ surfaces exhibit 
some degree of "shininess," greater brightness when the view- 
point is near the mirror direction. The specular brightness is 
strongly determined by how’ close the incident vector is to the 


230 


Chapter T 1 : Lighting and Shading 





mirror direction. The brightness generally decays rapidly as 
the vector deviates from that direction. 

The reflectivity of a specularly-reflecting surface falls off sharp- 
ly with angle away from the mirror direction. The following 
simple shading rule approximates this behavior. The incident 
light is scaled by 

Sspec = (N»H) 1/r0 ^ ftness 

where the vectors N and H are as showm in Figure 11.6. The 
larger the value of roughness, the roueher (less specular) the 
surface. 

A specular reflection is somewhat like a blurred image of the 
light source reflected in the surface. The question that natural- 
ly arises is: does a highly specular surface reflect the res: of its 
environment as well? Environment reflections may be pro- 
vided automatically, usually by a rav-tracing Tenderer that 
treats the reflections from other surfaces as it does other sourc- 
es of light. The RenderMan Interface also supports the use of 
an environment map to represent the rest of the scene as 
viewed from the surface. Use of an environment map is op- 
tional with the shader and will be covered in Chapters 15 and 
16. 

Specular reflections are important to the perceived realism of 
objects. Few surfaces are so diffuse that they scatter light uni- 
formly, and rendering all objects with just diffuse reflection 
lends an image an artificial "computer" look. Conversely, the 
focus and brightness of a specular highlight provide a lot of vi- 
sual information about the shape and texture of a surface. 

Choosing a surface shader 


RiSurface( name, parameterlist ) 
char “name; 

RiSurfaceO sets the current surface shader by name, thus con- 
trolling the appearance of the surface. The standard surface 
shaders are described below, together with their instance vari- 
ables for parameterlist. The default surface shader depends on 
the implementation. 
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In contrast to 
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shader is permanently associated with the sur- 
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Constant surfs 

RiSurfacei “conszan 


ce 

, RLNULL 


The constant 
turns the color 


Sfli 

of 


aaer ignores all light sources, and simply re- 
the surface and its opacity. 


Matte surface 

RiSurface: “mane' , 


"Kd", din jse, RLNULL ) 


RtFloat *amoier 


’diffuse: 


A matte surface 


t]v 

an 


weighted bv 
fRLKD). They 
spect conservati 
nents before surri: 


The ambient co{ 
summed contri 
turned on for the 


combines ambient and diffuse reflections 
e instance variables "Ka" (RIJ<A) and "Kd" 
■e coefficients (usually between 0 and 1, to re- 
on of energy) that scale the respective compo- 
ming them. 

inponent of a matte surface's shade is just the 
ution of all ambient light sources that are 
surface, scaled by Ka . 


The diffuse ref 
sources as des< 


cri > 


Both Ka and Kd ajre 1 bv default. 

Metal surface 


RiSurface,' “metal" 

"Ka", amb ent 
"Ns", speciiar 
"rougnnes 
RtFloat ’ambient 

A metal surface 
ular component 
shader uses the 
ables to scale the 
face reflection. Bolt: 


ection is calculated from non-ambient light 
■ed above. It is scaled by Kd. 


troughness, RLNULL ) 

’specular, ’roughness; 

•eflects light with only an ambient and a spec - 
Similar to the matte case, the metal surface 
"Ka 1 ' (RI_KA) and "Ks” (R!_KS) instance vari- 
ambient and specular components of the sur- 
:h variables default to 1. 
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The sharpness of the specular reflection is controlled by the 
roughness parameter. The reflection falls off away from the 
mirror direction as rapidly as 1 /roughness: a value of rough- 
ness near 0 sharpens the highlight to a point. As roughness 
increases toward infinity, the specular falloff goes to 0. 

Plastic surface 

RiSurtacet "plastic". "Ka", ambient, 

"Kd", diffuse. 

"Ks\ soecular, 

"roughness", roughness. 

"specuiarcolor'’, specularcolor, RI_NULL 
RtFloat ’ambient, ’ciffuse, ‘specular, ‘roughness; 

RtColor specuiarcolor; 

A plastic surface has ambient, diffuse, and specular reflec- 
tions. As before, they are scaled by the instance variables 
named "Ka", "Kd", and "Ks", respectively, declared with the 
shader and defaulting to 1. As with metal surfaces, the 
smoothness, or polish, of the specular component is con- 
trolled with the roughness parameter. The nearer roughness 
is to 0, the tighter the highlight. 

Unlike metal, the plastic shader colors the specular reflection 
differently than the ambient and diffuse components. Given 
by the instance variable specularcolor above, the specular col- 
or is used to govern the color of the specular reflection in the 
same way that the surface color governs the ambient and dif- 
fuse reflections. The components of the specular reflectivity 
scale the color components of the incident light, specularcolor 
defaults to white. 


Volume Shaders 

The idea of atmosphere affecting light passing through space 
between a surface and the eye is generalized in the concept of 
volume shaders. A volume is a region of space filled with any 
material that affects light passing through it. A volume can be 
as simple as a fog bank or a jello mold, or as complex as a hu- 
man body captured by a CAT scan. Each has different effects 
on the "light" passing through them. 
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A — Atmospnere shader 
E — Exterior shader 
I — Inteno' shader 
S — Surface shader 




Figure 11.8 Voiumd shaders i r. the rendering process 



The effect of a volume cannot be captured by a surface descrip- 
tion. Jello, for example, affects light all along the path through 
the volume. Thfe effect of a volume is fundamentally differ- 
ent from that of a surface. 

RenderMan specifies that volume calculations are performed 
by volume shaders. They are invoked by the Tenderer and giv- 
en the intensity, color and direction of light entering a vol- 
ume. They calculate the intensity- and color of the light leav- 
ing that volume. 

Figure 11.8 shows how volume shaders fit into the rendering 
process. After a light source determines the light arriving at a 
surface, the exterior volume shader associated with the sur- 
face is called to modify the light, then the surface shader does 
its work. If the surface is not opaque, light passes through the 
volume interior to the surface, and the interior shader is 
called to calculate the effect on that light in traversing that 
path. On the path from surface to camera, the atmosphere 
shader is called. 
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The job of specifying volume shaders is complicated some- 
what by the fact that there is no notion of a volume as, say, a 
geometric primitive in RenderMan. Instead, volume shaders 
are associated with the surfaces that bound them. The shader 
that represents the volume on the inside of an object is de- 
clared with Rilnterior(), and the volume on the outside is de- 
clared with RiExterior(). The volume through which light 
moves in going from a surface to the camera is declared with 
RiAtmosphereQ. 


Riinteriort name, parameterlis : ) 
char ‘name; 

RiExterior( name, parameterlis r ] 
char 'name; 

RiAtmospheret name, parameterlis : ) 
char “name; 

RilnteriorO sets the current interior volume shader associated 
with subsequent surfaces, and RiExteriorO sets the current exte- 
rior shader. RiAtmosphereO sets the current atmosphere shad- 
er. 

Whenever light approaches a surface (as from a light source), 
the surface's exterior shader is called to modify the light be- 
fore it strikes the surface. Whenever light passes through an 
object, the interior shader associated with one end of the path 
is called to modify 7 the light. It is an error to associate different 
interior shaders with different parts of an object. When light 
reflects from a surface on an unobstructed path toward the 
eye, the current atmosphere shader is called. 

The current shader of each type is an attribute of the graphics 
state, saved and restored like any other. There are no default 
volume shaders of any kind. 


The use of interior and exterior volume shaders is beyond the 
scope of this book. In fact, volume rendering is just coming in- 
to its own as a technique for visualizing multidimensional da- 
ta. The orientation of this book is tow r ard realistic computer 
graphics, but volume rendering creates the possibility of a va- 
riety of other "realities" for computer graphics. 
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A volume shap 
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environment c 
dependent!}' s 
sphere shader 
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er can be used to introduce an} 7 atmospheric ef- 
llight reflecting from a surface toward the eye. As 
laders, there is only one of these shaders in the 
a time, and it is associated with each object in- 
' that different objects may have different atmo- 
. Unlike surface shaders, there need be no at- 
der, and that is the default. If no atmosphere 
r. specified, light passes free of any atmospheric 
a surface and the viewer. 


Depth cues 

RiAtmosphere 1 a 


RtFloat Tninde 

RtColor cackerounocoicr; 


The depth-cue 
the reflected 1: 
face and the \ 
away, the arr: 
than mindeoth 


changed, 
mixed linearly 

Fog 

RiAtmosphere "to 

"ba 

"o 

RtColor rogcol 
RtFloat ‘distan 


"?pthcue' . 

' nmoistance’, mindepth, 
axdisiance', maxdepth, 
icKgrojnd’, backgroundcolor, RLN!U. 
?prr. ’maxdepth; 


shader mixes the color backgroundcolor into 
ght according to the distance between the sur- 
iewpoint. If the surface is more than maxdepth 
ving color is entirely backgroundcolor. Nearer 
the reflected color arrives at the camera un- 
-roih mindeoth to maxdepth , backgroundcolor is 
ntc the reflected color. 


ckground", fogcolor, 
ikance", distance, RI_NULL ) 
or; 

:e; 


The fog shade]; like the depth-cue shader, mixes a color into 
the light according to the distance between the surface and the 
viewpoint. The difference is that fog-shaded light always re- 
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tains some of the original reflected color. The fog is mixed in 
with weight (]—e~ l * e P tn 1 Pittance y which is 0 at depth 0 and in- 
creases with increasing depth but never reaches 1. 

Figure 11.9 illustrates the difference. The scene is shown at 
right with depth-cueing and at left with fog. 


Other Shaders 

This chapter has discussed and presented the standard light 
source, surface and atmosphere shaders, and touched lightly 
on volume shaders. A variety of other types of shader are 
specified by the RenderMan Interface, but none have standard 
shaders associated with them, which makes discussion diffi- 
cult. However, using any other shader should be straightfor- 
ward after mastering the basic protocol presented here. Chap- 
ters 13 through 16 provide more information. 

Further Reading 

The topic of lighting and shading is a rich one in the comput- 
er graphics literature/ because there is both so much to do and 
so much room for clever tricks. The model of specular reflec- 
tion used in RenderMan is due to Jim Blinn [BLINN77], and 
the model of metallic reflection to Rob Cook [COOK81]. A 
good recent survey of the field is the book Illumination and Col- 
or in Computer Generated Imagery [HALL89]. 
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CHAPTER 12 


Surface Mapping 


r . The lighting and shading discussion of the last chapter 
* covered the broad aspects of coloring objects in a 
scene,, in the following sense: both shaders and light 
sources apply to objects in their entirety. However, singly-col- 
ored objects, no matter how well lit, provide only simple visu- 
al information. It is the small variations of shape and shading 
within a single object that provide much of the visual interest 
and credibility of natural scenes: the wood grain of a piece of 
furniture, the tiny marks of paint on a wall chipped and 
cracked with age, the play of light on a fine fabric, the veins 
on a leaf, the subtle blushes and textures of human skin, even 
the text on the cover of a book or a picture in a frame demon- 
strate a richness in the visual world well beyond the complexi- 
ty of the objects themselves. 

It might be possible to provide these kinds of texture by using 
smaller and more numerous surfaces, but it multiplies the 
cost of transmitting and storing data and of resolving their 
hidden surfaces. Conceptually, detail is not associated with 
the shape and configuration of the objects, but with their ap- 
pearance. From a modeling standpoint, it seems sensible to 
deal with the two domains separately; to design, for example, 
the shape of a book first, then its cover. Finally, it is not clear 
that using a multiplicity of tiny objects will even work in all 
cases. There must be a better way to depict a photograph in a 
scene than to model every little change over its surface with a 
polygon. The better way is to distinguish shape, the geometry 
of a scene providing the basic conformation of objects, from 
shading, governing the appearance of those objects. 
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This is actually quite a natural idea. An interesting way to ex- 
press it is to visualize objects in the real world shaded by old- 
style computer graphics techniques. Imagine, for example, a 
wooden chair in a uniform, untextured, fiat plastic color. 
What is left is s' nape; what is left out, the difference between 
the visualization me the reality, is shading. 

We have already mentioned the interpolation process by 
arameters such as shading normal or color 
the extrema of a surface and interpolated to 
separation of shape from shading is to have 
there must be some finer level of control 
over object appjearance than simple interpolation. Shading 
riaracteristics must vary within an object, as well as among the 
n a scene. The discussion of this methodolo- 
be completed by specifying exactly the form 
ese capabilities under the RenderMan Inter- 
face, including specifying exactly hou shading is mapped onto 
surfaces. That is tie subject of the first part of this chapter. 

A second parr of the discussion is entirely new in this chapter. 
It is a venerable subject in computer graphics: the domain 
loosely described 

aee is mapped or to a surface in the manner of a decal. The dis- 
? maps has been deferred until now because 
optional capability- under RenderMan, and 
idard shaders use them. However, texture 
maps can be an extremely powerful tool for introducing detail 
and making a sc^ne visually interesting. The third part of this 
h generalizations of texture mapping to in- 
clude shadows, dhanges in the surface normal and reflections 
from the environment. 


These two topics 
the process used 
cessed using the 
ated with each pi 
polated across a s 
bound normals w 


of interpolation and mapping are linked by 
to lay textures onto surfaces. Textures are ac- 
two-dimensional texture coordinates associ- 
int on a surface. These coordinates are inter- 
4urface in exactlv the same wav as the vertex- 
used in Chapter 5. 


A sample texture 


Figure 12.1 show 
texture has been 
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Figure 12.1 Mapping a texture onto a surface 


tv used exactly as a color specified with RiColorO would be 
used to calculate the surface shading. Since the "constant" sur- 
face shader is used in this example, it reveals no changes in 
lighting. 


Simple Surface Mapping 

Earlier chapters have set out the parameterlist mechanism for 
binding an extensible set of parameters to surfaces and shad- 
ers when they are passed to the interface. We've mentioned 
several times the examples of color and surface normal 
bound to the vertices of polygons, but much is still unex- 
plained: what kinds of values can be interpolated? How are 
values interpolated for surfaces which, like quadrics, have no 
vertices? How can these interpolated values be used for the 
kinds of surface variations we seek? 

Varying vs. uniform variables 

Our purpose in this chapter is to allow the appearance of a sur- 
face to vary across its extent in as many ways as possible. 
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Id a surface shader , then that same variable can be 
neterlist of a surface primitive. The value will be 
ever\' point on the interior of the surface as 
e corresponding surface shader is called to 
t, its like-named instance variable will have 
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Sometimes we * 
We declare the 
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face, the variable 
application wish* 
to some value. 


For an arbitrary 
primitive surface 
ber of values to 
of variables pre< 
but V, T and 
chapters; they w: 


Other variables 
the function RiD^cIareO 


rant a value to be constant across a surface, 
’ariables carrying these values to be uniform, 
a variable to be interpolated across the sur- 
is declared to be vanring. For example, if an 
es to force the geometric normal of a polygon 
it can include an RLNP name-value pair in 
the parameterlisi lof RiPolvgonO. 


value to be used in the parameterlisi of a 
the svstem must know the tvpe and num- 
expect in each token-value pair. There is a set 
Refined in RenderMan, listed in Table 12.1. All 
have already been discussed in previous 
111 be covered in the next section. 


Extending the $et of variables 


jnay be added to the list of Table 12.1 by using 


RtToken RiDeclare( name, declaration ) 
char "name; 
char ’declaration; 

RiDeclareO makes a new variable known to the interface for 
use in the parameterlist of geometric primitive routines and 
shader declaration functions, name will be used in the token- 
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value pair to identify instances of the new variable, declara- 
tion is a string giving the variable's storage modifier (either 
"varying" or "uniform") followed by its type, either "float", "point", 
"color" or "string". The call 

RiDeclare! "temp", “varying float" ); 

declares that variable "temp" has a single floating-point value 
at each vertex. 

Only the predefined "st" and "Pw" vanables have more than 
one element at each vertex. No such vanables may be de- 
clared with RiDeclareQ. 


The RI_P variable in Table 12.1 would be declared as 
RiDeclare- "P", “varying point" ); 

RiDeclareO returns a value of type RtToken, which can be 
used as a token in a token-value pair for the variable in- 
volved, as in 

RI_TEMP = RiDeclare “temp", “varving float" 

RiPolvgom4. Ri_P, (RtPointeri vxvals, 

RI_TEMP, (RtPointer tempvals. RI_NULL); 

Using an RtToken this way may be more efficient than passing 
strings. 


Information 

Name 

Class 

! Type 

Number 
of Values 

Position 

■ „ p ., 

j varying 

RtPoint 

i 


! "Pz" 

| varying 

RtFloat 

i 


■ «p w » 

varying 

RtFloat 

4 

Normal 

I "N“ 

| varying 

RtPoint 

i ! 

1 

”Np“ 

uniform 

RtPoint 

i 

i Color 

"Cs“ 

varying 

RtCoior 

i 

Opacity 

“Os" 

varying 

RtColor 

i 

Texture Coordi- 

IlgJI 

varying 

RtFloat 

i 

nates 

H^Jt 

varying 

RtFloat 

i 


V 

varying 

RtFloat 

2 


Table 12.1 Predefined Variables 
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Figure 12.2 Parameier svace of a bicubic patch 


The underlying rectangular coordinate system imposed on a 
surface is known as the surface's parameter space. The names 
used by RenderMan for the coordinates of its parameter space 
are the conventional u and v. 

Patch and mesh interpolation 

The parameter space of a bicubic or bilinear patch occupies ex- 
actly the range 0 to 1 in both directions: points along the edges 
of the surface have either a u value of 0 (which we will refer 
to as the "left" edge of the surface), a u of 1 (the "right" edge), a 
v of 0 (the "top" edge) or a v of 1 (the "bottom"). The parame- 
ter coordinates of all interior points lie within those bounds. 
Figure 12.2 illustrates. 

This parametric coordinate system can therefore be used to 
find an interpolated value at any interior point on the sur- 
face, given values at the four comers. Specifically, if val qq is 
the value at the top left comer, and so on as shown in Figure 
12.2, then the value at any interior point (u, v) is given by bilin- 
ear interpolation: 
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The meaning of this for applications is very simple: the pa- 
ra meter list of ary parametric surface or quadric can be used to 
value just as it can for polygons. The applica- 
provide a token-value pair, where the value is 
xactly four elements: the values at [u,v) = (0,0), 
1,1), in that order. This is different from the order 


interpolate any 
tion need only 
an array with e 
(1,0), (0,1), and 


of polygon vertices, which are circular around the surface. The 


interpolant has 
ners, and each 
tween the two. 


The case of bili: 
complicated. Re; 
of representing 


one of the array values at each of its four cor- 
interior point is a bilinear interpolation be- 


iiear and bicubic patch meshes is slightly more 
seal) that a patch mesh is a more compact way 
5 rectangular array of patches that fit together 
'continuously at [their boundaries. A patch mesh declared with 
nu vertices in jhe u direction and an evaluation step of nusiep 
will have N = inu-S) / nustepPl patches in u, and similarly for v. 
For a patch mesh with N patches in the u direction and M 
patches in the v direction, the array of vertex values will con- 
tain exactly (N-TM.M- 1 ) values in u,v order if the patch 
doesn't wrap around, and N*M if it does. This declaration of 
patch vertex values has no effect on the coordinate system: the 
entire mesh is still covered by the range [0,1] in u and r. 

The parameter soace of a patch has another important use. A 
patch or patch mesh may be specified as a height field by pass- 
ing each point on the control mesh as a single floating point 
value, the height of that point. The x and y coordinates of the 
mesh are set equal to the u and v parametric surface values. 
Therefore, a patch derived from a height field ■will have an x 
and y extent across the square covering the range [0,1]. This 
scheme provides a compact representation for terrain data, 
and is also a convenient form for rendering functions in two 
dimensions. 


Quadric parameter space 

How does interpolation work for a quadric surface? What are 
the comers of a sphere, for example? Quadrics are also rectan- 
gles for purposes of binding values. A cylinder may be imag- 
ined as a rectangle twisted around to make two opposite edges 
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Figure 12.3 Parameter space on quadric surfaces 


coincide; similarly for a cone, if one edge has no length. A hy- 
perboloid is formed from a line segment in 5-space swept 
about a coordinate axis; the starting and ending positions of 
that line segment define two opposite edges of the rectangle, 
and the circles swept out by its endpoints the adjacent edges. 
For a sphere, the coordinate space is that of latitude and longi- 
tude. Figure 12.3 should help in visualizing this. The quadric 
declaration diagrams in Chapter 4 included this u,v informa- 
tion. 

The parameter space of a quadric arises naturally from the fact 
that quadrics are surfaces of revolution equivalent to sweep- 
ing a curve in 3-space around some coordinate axis. In a quad- 
ric surface, v runs from 0 to 1 along that basis curve, and u 
runs from 0 to 1 about the circumference of the revolution. In 
other words, u is longitude and v is latitude. 

This is true regardless of the radius of curvature, and especial- 
ly regardless of the sweep angle of the quadric, or zmin and 
zmax values in the case of a sphere. The surface of a quadric al- 
ways exactly occupies the parameter range 10,1]. A hemisphere 
covers the same "parameter area" that a sphere does. 
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Uses of parameter space 

The ability to map between points in parameter space and 
points on the surface of a geometric primitive is key to con- 
trolling the appearance of surfaces. We have already seen 
how surface parameterization defines interpolation of values 
across the surface. But there are at least three other important 
uses of parameter space: shading, trim curves and texture 
mapping. 


Shaders and surface maps 
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Trim curves 

Using an optional capability defined under the RenderMan In- 
terface, an application can cut out arbitrary regions of a non- 
uniform rational B-spline (NURB) surface. Standard patch de- 
scriptions result in a surface which is basically a warped rect- 
angle. The abilitv to describe trim curves on a NURB surface 
can provide more flexible shapes. 

Declaring trim curves 

A trim curve is a set of loops defined in the parameter space 
of a NURB. Each loop divides the surface into points inside 
the loop and points outside it. If the loop is defined counter- 
clockwise (as viewed on a rectangle with u positive to the 
right and v positive downward), the interior points are dis- 
carded from the surface (the loop cuts a hole). If the loop is 
clockwise, the exterior points are excluded (the loop is a cook- 
ie-cutter). The final surface consists of points left after every 
loop cuts points away. Using trim curves, a surface can be bro- 
ken into an arbitrary number of disjoint pieces. 

Each loop of a trim curve is a closed series of non-uniform, ra- 
tional B-splines in two dimensions, the parameter space of 
the surface being cut. 


RiTrimCurvei nioops, ncurves, order, knot, min, max, n, u. v, w ) 

Rtint nioops, ncjrvesl], order[], n [] ; 

RtFloat knot(], mini], max(J, u[], v(J, w(]; 

RiTrimCurveO declares a list of closed loops. Each loop consists 
of a sequence of NURB curves in (u,v) parameter space with 
homogeneous coordinate w. The curves of a loop must join 
to form a closed path. 

The number of loops is nioops. The number of curves in the 
Nth loop is given by ncurves[N] for 0 <N< nioops. 

The total number of curves in the trim set is 

nloo ps-l 

C - ncurves[N] 

N= 0 
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If 0 <m < C-l , then order{m ] gives the order of the mth NURB 
and n[m ] the number of control points on that spline. For the 
mth spline, there should be n[m] elements of u[], vfl, and w[], 
giving control points for the spline in the parameter space of 
the NURB. There should also be (orc/er[m]-rn[m]) values in 
knot[] giving the knot values of the spline. The spline will be 
evaluated between min[m] and max[m]. 


Parameter space in texture mapping 

The final important use of surface parameterization is in tex- 
turing: modulating the appearance of a surface based on the 
contents of an independent image. In fact, surface parameter- 
ization is the link between variable interpolation and the next 
section, which describes RenderMan's texturing facilities. 

re Maps 

The rectangular) parameter space of quadrics and parametric 
surfaces is good for more than just interpolating vertex val- 
ues. It also m4kes it straightforward to map textures onto 
those surfaces. 

A texture map is a rectangular digital image, so it too has a 
rectangular coordinate system: each point in the image has a 
unique pair of coordinates, designated 5 and i . A texture map 
in the RenaerMan Interface exact!} 7 covers the unit square [0,1] 
in s and i, regardless of the resolution of the map. The top left 
corner of the image is at (0,0) and the bottom right is at (1,1). It 
is no coincidence that this range exactly matches the parame- 
ter space of the most common primitive surfaces: a texture 
map applied to a quadric or parametric surface will exactly cover that 
primitive under r/iej default parameterization. 

Parameter- to texture-space mapping 

There is a reason, though, for making a distinction between 
the parameter space of a surface and the texture space of a tex- 
ture map. Surfaces are commonly joined together to form 
larger composite objects. In these cases, the need arises to ap- 
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ply a texture over the object as a whole. There must be some 
way of going from the "local" parametric coordinate system of 
a primitive to the "global" coordinate system of the object. 
This projection is specified using the routine RiTextureCoordi- 
natesO. 

The mapping between parameter space and texture space is 
controlled by giving the four coordinates of a quadrilateral in 
texture space. The unit square [ C0,0),(1 ,0),(0,1 ),(1,1 )] in parame- 
ter space (which just covers most surfaces) of a single surface 
is projected onto the given rectangle in texture space. This pro- 
jection is akin to pinning that part of the texture map down 
onto the entire surface primitive. A set of adjoining surfaces 
can be textured by RiTextureCoordinatesO calls that assign in- 
dependent but adjoining portions of the texture space to each 
surface. 


RiTextureCoordinatesi si. tl, s2, t2, s3, t3, s4. t4 ) 

RtFloat si . tl ; 

RtFioat s2. t2; 

RtFloat s3, t3: 

RtFloat s4, t4; 

RiTextureCoordinatesO declares a projection from the unit 
square [(0,0),(l,0),(0 y l )] in parameter space to quadrilateral 
[(shtl)As2,t2),(.s3,t3),(s4,t4)] in texture space. It therefore 
projects a part of a map onto an entire quadric or parametric 
surface (if the quadrilateral is within the unit square), or dis- 
tributes multiple copies of the map across the surface (if the 
quadrilateral is much larger than the unit square). 

The mapping projection defined by RiTextureCoordinatesO is 
an attribute contained in the graphics environment. It is 
saved and restored with other attributes, and it is assigned to a 
surface when the surface is declared, unless the surface is a 
polygon. 

The texture coordinates of polygons are the same as their pa- 
rameter-space coordinates, unless the former are bound to 
vertices and interpolated; that is, RiTextureCoordinatesO has 
no effect on polygons: texture coordinates must be explicitly 
bound to polygon vertices if the default is not sufficient. 
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Figure 12.4 Surfaces generated by the program in Listing 
linear patch zeiik iefaul: texture coordinates ; on the righ ; 


10, 5]. 10, 51 


Texturing anc' 


parameterlist 


.1. On the left, a ti- 
the texture space is 


The texture coordinates for a primitive can be specified in the 
parameterlist of the procedure creating the surface. The tokens 
V (RLS) and Y (RJ_T) label an array of single-value texture co- 
ordinates, and st*' (Ri_ST) labels an array of texture coordinate 
pairs that are applied to vertices and interpolated the same 
way as any other parameter. The coordinates themselves are 
RtFloat values 


Two examples 1 

Listing 12.1 shows a program fragment exercising the texture- 


mapping faciliti 
ure 12.4. Both 
“mytexture" used 
None of the st 
see in later 
RenderMan Shao 


es of RenderMan. The result is shown in Fig- 


an 


chapti 


There is only 
means of pass: 
"mytexture" surf£ 
“grid.txt* 1 is pas, 
method of passin 


of these examples assume that the shader 
to render the surface uses a texture map. 
dard RenderMan shaders do, but as we will 
:ers, such shaders are easy to construct in the 
mg Language. 

One noteworthy feature of this example: the 
the name of the texture map to the 
ce shader. The string pointer to the name 
by address , in contrast to the usual (in C) 
g it by value. 


sed 
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static RtColor color = , 0.9, 0.9, 0.9}; 
static RtPoint corners*] = I { -1, .3, 1 }, 

! i, -.1, i i, 

M , -. 1,-1 }, 

I 1, 3,-1 } 

I; 

static struct { RtFioat x, v 1 textcoordsfj = I 
{0,0 1,10.5,0 1/1 03,0.5 !, {0, 03} 

): 

char *imap = "grid.txt": 

Ri Declare' "tmap", ’'uniform string” }; 

RiSurface' "mvtexture” RtToken ) H tmap", RtPointer ;&tmap RI_NULL); 
RiColorf color ; 

RiT ranstormBeginO; 

RiTranslate< -1 3 23. “ .0 ; 

RiRotate*. -50.0. * C. C3, 0.0 }; 

RiPatchi ’‘bilinear RIJ 5 RtPointer comers. RLN'ULL 

RiTransformEndP; 

RiTransform Begin i); 

RiTranslate* 1 .0. 03 ‘ .0 ; 

RiRotate; -40.C. ‘ 5 2.0, 0.0 

RiPatchi !, biiine='* R:_P, RtPointer corners. 

R:jT RtPointer > textcoords. RLNL LL : 

RiTransform End 0* 

Listing 12.1 Program Gagmen: for generating Figure 12.4 


Textured quadric 

Figure 12.5 shows the bowling pin from Chapter 4, this time 
textured with the "grib.txt" texture used in Figure 12.2. The rou- 
tine in Listing 12.2, used to generate Figure 12.5, defines a tex- 
tured surface of revolution formed from a number of hyper- 
boloids. The most useful function of the routine is to divide 
the texture map among the segments of the surface. Normal- 
ly, each hyperboloid in the surface would be just covered by 
the entire texture map; here, however, they were textured 
smoothly by dividing texture space among the hyperboloids. 
On the left, each of the N surfaces gets 1/Nth of the texture 
space. On the right, the distribution of texture is equalized 
among the rings based on the surface's vertical extent. 
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^include <ri.h> 


tvpedef struct j RtFloat x, y; ) Point2D; 


A 

* MapSurfORt 

* The firs i s 

* indivibua 

* is eouaiiZ' 

V 


produce z surface ot revolution from z profile curve, 
jrface has a texture distributed evenlv among its 
rings. In the second surface , the texture distribution 
' ?d according to the size of the ring. 


MapSurfOR 1 poihts, npoints > 
Poini2D points; 
int npoints; 

{ 


double tot 
RtFioat t 

int pt; 


en. xlen, vlen; 
chords [NPOINTS]; 


A Distribute 
foupt * 0; 
tcoorto; 

RfTransrortn 
RiTr, 

TextS 
RiTranstor nEnd 


the texture interval fO , 7) linearly among the surfaces 
< npoints* pt-M-) 
isipt; = ((Tioat)pt)/(npointsT): 

BeginO; 

"anslate -0.6, 0.0, 0.0 ); 
unORf points, tcoords, npoints, 360.C 


Eaualize 
tcoordsfOj 
tor(pt = 0; 
xien 
vlen 
A Se: 
tcoo: 
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the texture coordinates */ 
totien = 0; 

< npoints- 1 ; pt++ { 
pointsipi-rl ).x-pointsipt] .x; 
pointsipt-O ].v-pointslpt].y; 

tcoordsii] to the accumulated length of all segments <= i */ 
fi-r 1 ] = (totien +=£ sqrt(xlen*"xlen+yien*ylen)); 


•riisipi 


A Normal ii e the accumulated lengths to the intent 1 10,1] */ 
for(pt *s 1 ; pt < npoints; pt+-f) 
tcoorqslpt] /= totien; 

A Declare the surface again 9 f 
RiT ransforrroBeginO; 

RiTrar slate( 0.6, 0.0, 0.0 ); 

TextSirrOR( points, tcoords, NPOINTS, 360.0 }; 
RiTransforrrlEndO; 
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* TextSurtORQ; create a surface of revolution with a texture , distributing 
texture space among the segments 

V 

TextSurfOR( points, tcoords. npoints, thetamax ) 

Point2D points[]; 
int n points; 

RtFloat tcoords}], thetamax; 

! 

int pt; 

RtPoint pointl, ooint2; 

RtFloat *ppi. m ?p2, *tmp; 

RtFloat thisT, nextT; 
char *tmap = "grid.txf 1 ; 

RiAttributeBeginO; 

ppl = pointl 1 
pp2 = point2; 

A 

* For each adjacent pair of points in the description , 

* draw a hvperboloid bv sweeping the line segment defined b\ 

* those points aoout the z axis. 

«/ 

ppl [01 = pomtsiOJ.v 
pplfl] =0; 
ppl [2] = pointSi’OJ.x; 
nextT = tcoords [0]; 

RiSurface^mviexture", 

.‘RtToken; "tmap", (RtPointeD &tmap. RLNULL}; 
RiRotate'90.0. 0.0, 0.0, 1.0); 
for( pt = 1 ; pt < npoints; pt+* ) I 
pp2[0j = points fptj.y; 
pp2(l ] =0: 
pp2[2j = points [ptj.x; 
thisT = nextT; 
nextT = tcoords ( pt]; 

RiTextureCoordinates(0.0, thisT, 1.0,thisT, 0.0, nextT, 1 .0, nextT); 

RiHvperboloid( ppl, pp2, 360.0, RLNULL ); 

tmp = ppl; ppl = pp2; pp2 = tmo; A Swap pointers V 

} 

RiAttributeEndO; 

1 


Listing 12.2 Routine used to draw Figure 12.5 
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Making a texture map 


A texture mar is created from an image file using RiMakeTex- 

* O O 

tureQ: 


RiMakeTexture" jts 

sgefiie, texturefile, swrap, twrap filterfunc. 

swidth. 

r width parameter! ist ) 

char * imagefile 

, ‘texturefile; 

RtToken swrap, 

. twrap; 

RtFloatFunc fill 

tehunc: 

RtFioat swidth, 

]twidth; 


RiMakeTextureQ creates the texture file named texturefile 
from an image file named imagefile. The resolution of the tex- 
ture file is similar to that of the image file, but the texture 
space of the map is still over the range [0,1] in both s and t, re- 
gardless of resolution. By definition, channels of the image 
are converted to channels of the texture map. Neither file for- 
mat is dictated by RenderMan, but should be specified in any 
implementation. 
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filterfunc is a pointer to the function used to filter the pixels of 
the image. As with pixel filtering in image rendering (see 
Chapter 9), the functions RiGaussianFilterO, RiCatmuIlRomFil- 
ter(), RiSincFilterO, RiTriangleFilterO and RiBoxFilterO are pre- 
defined under RenderMan, and the application can define 
others as RtFloatFunc fund), swidth and twidth give the sup- 
port of the filter, the number of pixels in s and t used in filter- 
ing each element of the texture map. swidth and twidth are typ- 
ically 1 or 2. 

swrap and twrao refer to the behavior of the texture map 
when it is accessed outside the range [0,1]. If "oeriodic" 
(RI_PERIODIO, the texture wraps with a period of i. If "damp" 
(RI_CLAMP), the value at the nearest edge will be returned for 
out-of-bounds access, "black" (RI_BLACK) means to return 0 
outside [0,1]. The parameterlist of RiMakeTexture'f may be 
used to pass implementation-dependent information to the 
texture creation routine, but no standard parameters are de- 
fined. 


As noted above, the resolution of the input image file affects 
only the quality of the texture, which alwavs exactly occupies 
the range [0,1]. 


Texture Mapping Generalized 

Given the ability to modulate the reflectivity of a surface 
across its extent by using a texture map, one might wonder 
whether it wouid be useful to modulate other surface proper- 
ties in the same way. The RenderMan Interface provides di- 
rect support for three generalizations of simple texture access. 
A bump map controls the surface orientation under shading, 
providing for subtle "bumpiness" effects on an otherwise flat 
surface. An environment map can provide glossy and mirror- 
like reflections of other objects from a surface via a rendition 
of what a scene looks like from the point of view of the sur- 
face. And a shadow map provides information for determin- 
ing whether a surface point falls in a shadow cast by a particu- 
lar light source. 
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n g 


mitive object types in the RenderMan Interface 
-defined surface normals: a polygon has a sin- 
rmal over its entire area, the normal of a quad- 
nges smoothly from place to place, and the nor- 
imetric surface is given by the cross-product of 
the surface in the u and r directions. While 
e variations in surface orientation are normal- 
tleresting as the single color that is used for shad- 
ce of texture maps. 


• to 
hes 


en 


Texture due i o surface modulation 


The classic ex: 
surface orier.ta 


ange appears 
one single colo 
ularitv. 


ample in computer graphics of texture due to 
don is an orange. At a superficial level, an or- 
to have a fairly simple, nearly spherical shape, 
everywhere on its surface and a constant spec- 
One siibtletv that makes an orange far less mundane 
is the tiny pits and undulations of its surface. 


Modeling surface modulations 


Obviouslv, the:' 


represented bv 


Se small modulations of the surface could be 
a parametric surface in which someone took 
the trouble to introduce all the little variations of shape indi- 
vidually. On a practical level, that procedure is not only pain- 
cumbersome, but it would onlv be good for one orange 
at a time. On a conceptual level, it seems to be using an object 
description to set out what should be a property of the surface. 
It fails to distinguish shape from shading. 

Once we recogn^e that we are dealing with a property of the 
surface, the key observation is that the position of each point 
on the surface pf the orange is relatively unimportant. The 
arriving in the middle of a pit is not signifi- 
from that arriving at the surface. Only the 
variation in the orientation of points on the surface makes 
much difference to the ultimate appearance of the orange. 

Whereas a texture map describes variations in the reflectivity 
of a surface, a bu^p map describes the variations in a surface's 
orientation . OtherWise, bump mapping is identical to texture 


amount of light 
cantlv different 
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mapping: a bump map file covers the texture-space range [0,1]/ 
with coordinates out of that range handled according to the 
wrap mode declared with the bump map. 

Making a bump map 

Just as with texture maps, a bump map can be made from an 
image file. 


RiMakeBumpf imagerile. bumpfile, swrap, twrap, tilterfunc. 
swidth. rwidrh, parameterlisi ' 
char 'irr.ageriie, “bumpfile; 

RtFloatFunc riiterrunc: 

RtToken swrap. twrao; 

RtFloat swidth, rwidth: 

RiMakeBumpO creates a bump map file named bumptlie from 
an image file named imagefile; its parameters have the same 
meaning as those of RiMakeTextureO. The image file should 
have a single channel which gives a displacement, or height, 
along which the surface should be perturbed. The perturba- 
tion is converted into changes in the normal by examining ad- 
jacent perturbations. Thus, a uniform displacement will cause 
no bumps at ail. The formats of the two files are implementa- 
tion-dependent. 


An alternative for bump mapping 

Bump maps have an honorable history’ in computer graphics, 
and can dramatically enhance the appearance of a surface. 
They do have one shortcoming, though. A bump map affects 
only the shading normal of a surface, not its true shape. This 
means that profile edges will never change, and there is no 
possibility of self-shadowing in the pits. This is not a big prob- 
lem if the modulations of the surface are much smaller than 
the surface itself, as they are in the case of the orange. 

RenderMan supplements bump maps with an optional facili- 
ty that can modify the actual geometry of a surface. A user can 
write and apply a displacement shader. Called once during 
rendering for each point on a surface, the displacement shad- 
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er has the opportunity to modify both the position and nor- 
mal of the surfc ce at that point. 


RiDisplacement n; 

char "name- 

ime parameter! 1st 

RiDisplacement 
state. Any sur 
only after the c 
face, name is a 
RLN'ULL, then 
points are nor 
token-value pc 
shader. 

0 posts a displacement shader to the graphics 
: ace declared under that state will be shaded 
ispiacement shader is called to perturb the sur- 
string giving the name of the shader. If name is 
no displacement shader is defined and surface 
perturbed, parameterlisi is an optional series of 
irs providing the instance variables of the 

The current dis 
ics state, and 2 
the state. 

placement shader is an attribute in the graph- 
; such it is saved and restored with the rest of 


Since displacement shading is an optional capability, no stan- 
dard displacement shaders are specified under the Render- 
Man Interface, put displacement shaders will be demonstrated 
among the example shaders of Chapter 16. 

Environment mapping 

Environment maps address the problem of interobject reflec- 
tions. In the real world, an observer sees parts of the world re- 
flected in glass, metal, water and other shiny surfaces as from 
a mirror. The most popular rendering method to include in- 
terobject reflections in an image is ray tracing. A ray tracer 
renders a pixel by casting an imaginary ray back into the world 
from the viewpoint, through that pixel. If the ray strikes a sur- 
face, it is shaded by casting rays from the point of intersection 
toward each light source in the scene. If the surface is suffi- 
ciently shiny, another ray is cast along the mirror direction 
from the surface. Any object that this latter ray strikes is seen 
as a reflection of the second object in the first. Figure 12.6 
shows this process. 

Ray tracing can be an expensive method due to its cost in com- 
puting time and the fact that it must store a scene in its entire- 
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transmit 



Figure 12.6 Inter object - ejections using ray tracing 


tv throughout the rendering process. Ray tracing also often 
suffers from aliasing problems due to the nature of cast rays as 
infinitely narrow. There is an alternative which also provides 
interobject reflections and which can often be more efficient, 
although it is less flexible. It is based on a simple fact of projec- 
tive geometry. A flat mirror reflects light toward a given view- 
point as though the surface were transparent, with the view- 
point behind it (see Figure 12.7). For purposes of rendering 
from the original viewpoint, a reflection map can be precom- 
puted from a viewpoint behind the surface. It can then be 
used to depict the refections by an appropriate mapping. 

Environment maps defined 

Many shiny surfaces can be approximated in a similar way by 
assuming a single viewpoint somewhere in the middle of the 
object and precomputing an image from that viewpoint. An 
environment map gives an image of the environment in all 
directions from a location inside an object. Unlike texture and 
bump maps, an environment map is not accessed by surface 
location, as expressed in texture-space coordinates. Rather, an 
environment map contains the appearance of the scene from 
a fixed point varying by direction. When rendering a surface us- 


Texture Mapping Generalized 


261 
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specular objects. It works best when the sur- 


argument for environment maps is that they 
filtering technolog } 7 as other kinds of maps to 
of depicting accurate reflections. Since the 
n adjacent traced rays can van* wildly in direc- 
global representation like an environment 
uch more tractable to filter reflections. 


/ ironment map 


routines for creating an environment map. 
n image indexed by the latitudinal and longitu- 
:s of a sphere. The second uses a set of six im- 
e, shape and viewing directions collectively 
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RiMakelatLongEnvironment( imagerile, reflfile, filterfunc, swidth, twidth, 
parameter! is: ) 
char “imagerile, “reflfile; 

RtFloatFunc filterfunc; 

RtFloat swidth, twidth; 

This makes the environment map reflfile from the image 
called imagerile . Except for the omission of the wrap parame- 
ters (which make no sense in this context), the parameters are 
identical to those of RiMakeTextureO and RiMakeBumpQ. 

The image file must be indexed according to a spherical projec- 
tion: if the map will be used under a left-handed coordinate 
system, longitude varies from 0 at the left to 360 at the right; 
under a right-handed coordinate svstem lonsituae is 360 at 
the left and 0 at the right. In both cases, latitude is -90 at the 
bottom and 90 at the top. A direction in space (dx, dy, dz) is a 
function of latitude and longitude : 

dx = cos(longiiude) * cos(latitude) 
dy = sm(longifude) * cos(laiitude) 
dz = sin( latitude) 


Any flat representation of a sphere (a map of the earth, for ex- 
ample) contains some distortion. The latitude-longitude envi- 
ronment map makes objects seen at the top and bottom ap- 
pear much larger than the same objects seen near the equator. 

A latitude-longitude environment map is often created using 
a paint system. An environment map can also be made by ren- 
dering a scene six times, once for each face of a cube centered 
on the object that will bear the reflection. Once rendered, the 
environment map is made by the following: 


RiMakeCubeFaceEnvironmentl px,nx, py,ny, p z.nz. reflfile, 
fov, filterfunc. swidth, twidth, parameterlist) 
char *px, *nx, “pv, *ny, “pz, *nz; 
char *reflfile; 

RtFloat fov; 

RtFunc filterfunc; 

RtFloat swidth, twidth; 
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This routine makes an environment map named ref I file us- 
ing six images corresponding to the six sides of a cube. Each 
ima^e has its viewing location at the center of the cube with 
viewing direction along the positive and negative x, y and r 
axes, respectively. filterfunc r swidth and twidth are the same as 
before, fov is the horizontal and vertical field of view of the 
images. An io\ j;va!ue of 90 would fit the cube faces exactly, but 
two or three degrees extra can provide a little overlap to im- 
prove the quaiitk of the resulting map. 

The six face vi|ews must have an orientation that depends on 


the axis they sis 

jht along, as detailed in the table below. 

Face View 

Axis toward top Axis toward right 

px 

-v -- 

nx 

-r 

pv 

-r 

n\ 

-r - x 

PZ 

-rl/ -,V 

nz 


The orientarior 

of these views is natural in a left-handed co- 

ordinate sysren 

■. For a right-handed coordinate system the}* re- 

present ien-to-r 

izh t mirror images 
° 

The orientaticd 

ls required of the images of the environment 

cube are (in a i 

lefr-handed coordinate system) those of a view- 

er facing the pi 

xsirix^e r direction who then swivels his head to 


face the various directions. The}' are illustrated in Figure 12.8 
and Plate 14. 

If the environment is rendered under a right-hand coordinate 
system, the orijentation of each view is exactly the same, and 
the same camera transformation may be used to render the 
images. However, they will appear to be flipped right-to-left. 

An environment map should be precomputed from the scene 
being rendered, but without the reflecting object so that the re- 
flections are accurate. Since the faces of the cube parallel the 
coordinate axes of camera space, the viewing transformation 
should do the following: 
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Figure 12.8 Drier* * ^ziovs of the -views passed to RiMakeCubeFaceEnviron- 
mentO 


• use a perspective projection with field of view of 90 de- 
grees or slightly more (see above), 

• translate from the origin of world space to the center of 
the object in question. 

Listing 12.3 gives a version of the rendering process to create 
six reflection images via six renderings, then create an envi- 
ronment map. 

Listing 12.4 provides a routine to use the resulting reflection 
map in a scene. It declares the object which will reflect the en- 
vironment (a sphere) after declaring a translation to the loca- 
tion of the environment map rendered earlier, then goes on 
to show the rest of the world. As before, this example posits 
the existence of a surface shader, "myretlector", which uses a re- 
flection map. 

Plate 15 shows the result of using the environment map creat- 
ed from Plate 14. While the reflection on the teapot is quite 
convincing, closer inspection reveals that neither the spout 
nor the handle are reflected in the body. However, the sendee 
to realism is substantial nonetheless. 
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AMakeRefl.c: create and use an environment map at a given viewpoint */ 


^include <ri.h> 

^define BUFSIZE 236 
RtPoint Camera From: 

mainQ 

f 

Rtlnt resolution; 

char filename | BUFSIZE], tfiienames(6][BUFSlZE-4/ 

GetCubeParmsi CameraFrom, filename, ^resolution •; 
RiBeginfRLNULL); A As always "/ 

RiDecl^re “refimao 1 , ‘‘uniform string"}: 

^ Render the faces of the cube V 
Snap 4-’', rfiienamesjO), resolution J; 

Snap, V , tfiienamesil], resolution }; 

Snap ‘i—", tfilenamesI2], resolution ); 

Snap: ' j-', tfilenamesjS;, resolution ); 

Snap: ‘‘j-", tfiienames* 4 ], resolution ); 

Snap tfiler.ameslS], resolution )■ 
RiMakeCubeFaceEnvironment. 
tfliienameslOj, tfiienamesil ], 
n)Ienames|2] tfilenamesI3], 
tillenames|4j, tfilenames[5], 

filename, 90.0, RiGaussianFilter, 2.0, IX RLNULL ); 

RiFram^Begin.7}' 

RlWorldBegin ; 

Go(fiienamej; 

RiWorldEnd, ; 

RiFrameEndO; 

RIEndQ; 

1 

Snap{ direction, tfiiename, resolution ) 
char “direction, tfiiertiame: 
int resolution; 

I 

int axis: 

static int framgnum = 1 ; 

RtPoint CamefeTo; 

sprintf(tfiienanie, “%s.%s", filename, direction); 

RiFrameBegin(framenum-r+); 

RiDispiay(tfilename, RI^FILE, RI_RGB, RLNULL); 

RiFormat( resolution, resolution, 1.0); A image resolution */ 
A Mature of the projection to the image plane V 
RiProjection( "perspective", RLNULL ); A perspective view */ 
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f* Camera characteristics m f 

FrameCamera( resoiution/2.0, (float)resolution, (float)resoiution ); 

/* Camera position and orientation */ 

CameraTofO] = CameraTop) = CameraTo(2] = 0; 

switchi'direction(Ol) I 

case 'x': axis = 0; break; 

case y : axis = 1 ; break; 

case 'z': axis = 2; break; 

! 

CameraTolaxis] = (direction}! }=='-') ? -1 : 1 ; 

PlaceCamera f CameraFrom, CameraTo, (RtFloat) 0.0 ); 

/* Now describe the world */ 

RiWoridBeginP: 

Col NULL)' 

RiWoridEndO; 

RiFrameEndO; 


Listing 12.3 F unction for creating environment maps for an object in a scene 


/» 

* Object description function for creating and using a reflection 

* map on a sphere, ifrr. apname is non-NULL. the function 

* assumes it to oe the name of a reflection map, Otherwise , 

* the function ignores the object and simply declares the rest 
K of the world . 

V 

extern RtPoint CameraFrom: 

Co(nnapname) 
char *mapname; 

I 

iftmapname != NULL) i 
RiAttributeBeginf); 

RiSurfaceC'my reflector", 

RtToken) "reflmap", (RtPointer &maDname, 
RLNULLfc 

RiTranslate(CameraFrom[0j,CameraFrom[2],CameraFromi2!); 
RiSphere* 1.0, -1.0, 1.0, 360.0, RLNULL ); 

RiAttributeEndQ; 

I 

ShowRestOfWorldO; 


Listing 12.4 Function for using an environment map in a scene 
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Figure 12.9 Depw-rcridc'-ed shadow map (data recorded by s'nadou' maps) 


Shadow maps 

The fourth type of map provided by RenderMar covers anoth- 
er special capability of ray tracing: rendering shadows result- 
ing from obiecrs blocking light sources. A shadow map begins 
as a depth image, rendered from the viewpoint of a light 
source. If the image contains, at each pixel, not the color of the 
nearest surface, put its distance, the result can be used to deter- 
mine whether ant' point in the scene is in shadow. Figure 12.9 
shows the depth image used in creating Figure 7.7; darker 
points are nearer the light. Any point visible in the depth ren- 
dering is illuminated by the light, and any points "behind" an 
illuminated surface are in shadow. 

A depth image is created by giving RiDisplayO the token Ri_Z 
as its mode, indicating that depth values rather than colors 
are being rendered. Once the depth image is created, it is trans- 
formed into a shadow map by the following: 
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RiMakeShadowf picrile, shadowfile, parameter! ist) 
char 'picrile; 
char "shadowfile: 

As usual, RiMakeShadowO takes a depth-rendered picture file 
picrile, producing a shadow map file shadowfile suitable for 
use by a shader that attends to these matters, picrile contains 
depth ("z") information. 


Listing 12.5 shows a simplified example for creating and using 
a shadow map. It assumes that Setupi) calls the RenderMan 
routines used to position the light source, SetupInvQ declares 
the inverse transformation, and DoSceneQ declares all the ob- 
jects in the scene. 

In the first frame block, SetupInvQ is used to position the 
world with respect to the camera; in the second, SetupO posi- 
tions the spot light. As explained in Chapter S, a camera trans- 
formation must be described as the inverse of a transformation 
used to position an object (in this case, a light) in the same lo- 
cation with the same orientation as the camera. 

The RiDisplav() call at the beginning of the first frame passes 
RI_Z in the mode parameter to cause a depth image "shdw.z" 
to be output. Since that call occurs inside the frame block, that 
specification is removed at the end, and the second frame us- 
es the default display parameters. In the second world block 
the light source is positioned and declared at the beginning be- 
cause the setup transformation is expressed relative to world 
space. 

A spot light has a default location at the coordinate origin of 
its object space and points along the positive r axis, just as a 
camera does. For that reason, both the camera and light point 
in the same direction after the transformation. As a result, the 
shadow is cast back into the world from whence it was taken. 
This only works because the “from" and "to" parameters of the 
spot light are left with their default values. If they were not, it 
w'ould ruin the coincidence of light and shadow. 

This example assumes the existence of a spot light shader 
named "shadowspot" w-hich takes the name of a shadow map 
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i! 

i\ 

: = 

^ F Create and use a shadow map for a spot light. V 

char "shadow® le = "shadowfile"; 

RiBegin(RI_N JLLj; 

RiDeclare “shadowfile'', “uniform string 1 '); 

RrFrameBegin l;; 

RiDisplav “shdw.z", RI^FILE. Rl_2, RLNULL); 

Setup! nv(j; 

R rWo rid Begin (j; 

DoSceneO; 

RiWoridEnti 

RiFrameEndO; 

RiMakeShadow “shdw.z", shadowfile, RI_NULL 
RiFrameBegin;!); 

RrlvorldBegin 

RiTransiormBeginO; 

SetupQ- 

RiLightsource; “shadowspof , 

(RtToken vl! shadowhieL'RtPointer)&shadowTiJe, 
RLNULL ); 

RiTransformEndO; 

DoSceneO; 

RiWoridEndQ; 

RiFramecnd 

RiEndO; 

Listing 12.5 F JttchoM for creating and using a shadow mar ■ for a tigki source 


in its ’’shadowfile” instance variable. None of the standard 
RenderMan shaders use shadow maps but any implementa- 
tion may support them and, of course, if the implementation 
supports the RenderMan Shading Language they may be writ- 
ten directly tshadowspof is defined in Chapter 16. 

Conclusion 

There are four different kinds of maps defined by RenderMan 
because their indexing and data are of different kinds. Other- 
wise, the basic idea of mapping, that of varying surface proper- 
ties across an object, applies equally to all. 

Although the data in each type of map has an implied mean- 
ing (color for texture maps, normal perturbation for bump 
maps, etc.), there is no reason that these interpretations must 
apply. For example, the information in a texture could be 
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used for any purpose. It might provide perturbation informa- 
tion to a displacement shader. It could represent airflow speed 
and pressure to a shader visualizing dynamic stresses. In fact, 
any variable relevant to shading can be stored in a map and ac- 
cessed by a shader that knows about it. 

Standard surface shading parameters apply to surfaces as a 
whole. In the first part of this chapter, we described how these 
parameters can be varied linearly across a surface by binding 
values to corners or vertices and letting the renderer interpo- 
late them and pass them to the instance variables of a shader. 
The different types of maps are nothing but the ultimate gen- 
eralization of this idea, allowing any numerical input to the 
shading process to vary arbitrarily. 


Further Reading 

The original work on texture mapping was done by Ed Cat- 
mull [CATMULL74], but perhaps a better source is Paui Heck- 
bert's survey [HECKBS4]. Bump maps were first discussed bv 
Jim Blinn [BLIXX7S]. The use of environment maps to simu- 
late reflections is set out by Blinn and Newell [BLIXN76] and 
detailed by Greene [GREEXE86J. Feibush, Levoy and Cook 
[FEIBUSH80] give insight into the filtering of texture maps. Fi- 
nally, the RenderMan shadow mapping technique is based on 
work by Reeves, Salesin and Cook [REEVES87], 
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CHAPTER 1 3 

The RenderMan Shading 
Language I: Introduction 


r Writing computer programs to synthesize digital im- 

* ages has always been a challenging undertaking. It be- 
gins with a marathon of programming: designing and 
implementing a hidden-surface algorithm, managing an ar- 
ray of complex data structures, performing a batten - of geomet- 
ric tasks and simulating the physics of light emission, trans- 
mission and reflection. When the first picture finally emerg- 
es, it is a cause for celebration. 

An important part of any renderer is the shader, the section 
that calculates the appearance of visible surfaces in the scene. 
The rest of a renderer deals with a fairly bounded, well-de- 
fined problem centering around data management and projec- 
tive geometry. Since the visual world is so rich, since appear- 
ance can vary so widely, the shader is the center of flexibility 
and power in a renderer. 

Once an image synthesis program exists, the shader also be- 
comes the focus of users' expectations. As visuallv oriented 

X * * 

animals, people are very sensitive to subtleties of shading, 
and that sensitivity expresses itself as a nearly limitless de- 
mand for subtle, flexible control over shading. At the same 
time, the more successful a program is, the wider the range of 
physical reality it is expected to duplicate. Both of these facts 
place extraordinary demands on the shading portion of any 
renderer. 

Usually, the shader is a large, complex body of routines em- 
bedded within a renderer. Viewed from outside, it appears as 
a nest of interacting options, parameters, maps and light 


273 


\ 


£T- 


nri' 


sources, a 
into doing 
approach a 
havior can 
shader is si 
one must re 
programme]', 
be a protrac 

This all rai$ 
imagen 1 an 
that should 
no accident 
ics are proa 
with progr. 
and the bn 
process will 
mands on a 


massive, mysterious system that can be massaged 
more or less what the user wants by a circumspect 
:id a delicate manipulation of parameters. Its be- 
Dnly be modified, not extended. If, in the end, the 
ply not able to provide a particular feature, some- 
vise the Tenderer itself. This is the domain of the 
, and even for a skilled programmer it is likely to 
led, touchy process. 

es the cost of creating truly compelling synthetic 
impedes the free flow of experiment and result 
exist between the creator and his or her work. It is 
that the most striking images in computer graph- 


uced by programmers or arusis working closely 
dmmers. The complex nature of physical reality 
eadth of the visual imagination ensure that this 
never end. There will always be unanticipated de- 
Jnonolithic shader. 


There is an alternative, based on giving the user more access 
to the shading system itself, rather than its external interface. 
The critical chine is to give users access to the useful parts of 
the system without burdening them with irrelevant details. 
Just as one shouldn't have to know about the chemistry of pig- 
mentation tc use a paint brush, there should be a way to con- 
trol the appearance of objects in a synthetic scene without an 
m-depth knowledge of the entire rendering program. Fortu- 
nately, the shading process can be tamed and brought under 
control that way. 

One key idea is to tease apart rendering issues dealing with 
substance frcm those of appearance. Image synthesis can be di- 
vided into two basic concerns: the shape realm of geometric 
objects, coordinates, transformations and hidden-surface 
methods; and the shading realm of light, surface, material 
and texture. The former is very specific: I want a telephone 
here, a 3-D logo there, a building over there. Geometry must 


be controlled 
often accompi 


more or less explicitly by the user. This is most 
ished with the aid of modeling software. 


Most of the visual interest of a typical scene, the place where 
credibility rerides, is at a level more subtle than the overall ge- 
ometry: the veins on a leaf, the aged sheen of the paint on a 
car, the textures of various materials, the subtle differences be- 
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tween real wood grain and those plastic simulations. A quick 
glance around any room is enough to convince anyone of the 
astonishing variety of materials in the real world. 

The confusion between shape and shading is wasteful if it 
leads users to seek complexity in geometry when it could be 
provided more easily during shading. As an example, consid- 
er fabric. Theoretically, a piece of cloth could be described geo- 
metrically as a net of polygons or parametric surfaces for each 
individual thread. But a more reasonable approach might be 
to describe the overall fabric geometrically, taking the appear- 
ance of the cloth as a shading problem. 

The RenderMan Interface is largely motivated by the idea that 
a lot of geometric complexity can be supplanted, with an equal 
level of visual interest and realism, by more flexible shading 
methods. 

It is difficult to provide this sort of flexibility in a monolithic 
shader. The presentation of shading as a predefined process 
under the control of a fixed set of parameters has fundamen- 
tal limitations. What could possibly take its place? The most 
adaptable creature in computing is the procedure, or subrou- 
tine. The key idea in the RenderMan Shading Language is to 
control shading, not only by adjusting parameters and op- 
tions, but by telling the shader what you want it to do directly in 
the form of a procedure. 

The programming procedure can become an uncommonly 
powerful lever for control over shading, both because its job 
can be verv tightlv defined in terms of the elements of the 
shading process (e.g., describing the light emerging from a 
light or reflecting from a surface), and because the author of 
the procedure doesn't have to worn* about such issues as elim- 
inating hidden surfaces or determining the geometric context 
of the procedure call. 

By writing an appropriate shader in the shading language, a 
programmer can extend old shading models or implement en- 
tirely new ones, light sources can be defined with any radiant 
distribution, and new and novel surface properties can be in- 
troduced easily. Any parameter to these processes can be set 
up with a constant value, a value that varies smoothly over a 
surface, or one modulated arbitrarily by a surface map. 
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shows the shading process as a dataflow model, 
ation of a surface color proceeding from errus- 
source, through reflection at the surface and 
e atmosphere. The process begins when a Ten- 
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Shading as 
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In Figure 13. 
light source tic 
at a surface pi 
tance between 


information flows from light to camera. A 
s a single purpose, to calculate the light arriving 
c-int, taking into account such factors as the dis- 
source and surface. 


A surface shader uses color of the light arriving from the light 
source, together with the color of the surface and other fac- 
tors, to calculate the light leaving the surface at that point. That 
information in turn is passed to an atmosphere shader, which 
may further modify it in calculating the light arriving at the 
image plane. Similarly, a volume shader affects light passing 
through some material. 
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A — Atmosphere shader 
E — Exterior shader 
! — Interior shader 
S — Surrace shader Y 



Figure 13.1 Dataflow model of shading 


Dataflow modules 

One of the important aspects of the shading language is that 
the shaders are functionally independent. The interaction be- 
tween one module and another is limited to the data items 
(light color, primarily) that pass between them. From the 
standpoint of the model as a whole, the internal operation of 
a shader is completely unconstrained. It doesn't matter how 
the surface shader determines its reflected color; it is only im- 
portant that it provide one. 

The normal view of programming procedures is that of fixed 
"black boxes" that have well-defined input and output and 
unknown internals so that they can be assembled into large 
systems based only on that external view. Shaders, by contrast, 
are embedded in a predefined system (the Tenderer), and the 
user's freedom lies in implementing or selecting the module 
itself. 

Shader types 

The RenderMan Interface specifies six types of shader, distin- 
guished by the inputs they use and the kinds of output they 
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produce. Several types of shader may each be used in different 
parts of the shading process. 

Light source shaders 

A light source shader is given the position of a light source, 
and the direction of a surface point from the light. It returns 
the color of the light originating in the light source and strik- 
ing that surface point. 

| 

Unlike most other shaders, there mav be several light sources 

- " 

in a scene at once, each declared with RiLightSourceO or with 
RiAreaLightSourceO. .Any subset of them may be turned on or 
off for anv surface in a scene. 


Volume shaders 

Volume shaders are associated with volumes of space both in- 
side and outside the objects of a scene. They describe the ef- 
fects on light of passing through a volume from an origin to a 
destination. If the path is inside some object, an interior vol- 
ume shader is called. An exterior volume shader is used to af- 
fect light which passes through "empty space" outside any ob- 
ject. A volume shader is called for light approaching the cam- 
era. 

A volume shader is associated with the volume interior to a 
surface by calling RilnterioK), with its exterior by RiExteriorO, 
and with the atmosphere by RiAtmosphereO. All the surfaces 
facing the interior of an object should have the same interior 
volume shader, ®r an error results. If there are several differ- 
ent exterior volume shaders defined in a scene, the choice of 
which one to use for a given path is implementation-depen- 
dent, but it will be the exterior shader bound to one of the sur- 
faces at either end of the path. 

Transformation shaders 

Transformation shaders are really part of the geometric pro- 
cess rather than shading. The geometric transformation capa- 
bilities specified by RenderMan include both matrix opera- 
tions and the ability 7 to apply arbitrary nonlinear transforma- 
tions (called deformations) to geometric coordinates. These 
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are specified with a transformation shader, which takes a 
point in space and outputs another point. A transformation 
shader is concatenated onto the current transformation by call- 
ing RiDeformationO. A nonstandard geometric projection 
from camera space onto the image plane is specified by calling 
RiProjectionO, naming a transformation shader instead of 
“perspective" or "orthographic". 

Displacement shaders 

Transformation shaders and displacement shaders are similar 
in their mission of moving points in space. They differ, how- 
ever, in their respective place in the rendering process and 
their relationship to object geometry. A transformation shad- 
er is the nonlinear equivalent of a transformation matrix in a 
concatenated series, transforming points without regard to 
any associated surface. Consequently, a deformation may be 
embedded within a series of linear and nonlinear transforma- 
tions and used to deform any geometric aspect of a scene. The 
purpose of a transformation shader, then, is to modify a coordi- 
nate system. 


The purpose of a displacement shader, on the other hand, is 
to perturb the surface of an object point by point, providing de- 
tail in the form of small variations that would be much more 
difficult to specify geometrically. It operates entirely on the 
surfaces of objects. Unlike a transformation shader, a displace- 
ment shader may use the surface normal, parametric deriva- 
tives or any other property of the surface in calculating the dis- 
placement. Finally,, a deformation is made part of the current 
transformation, while a displacement is associated with indi- 
vidual surfaces like any other attribute. Displacement shaders 
are instanced with RiDisplacementO. 


In Chapter 16, the threadsO shader in Listing 16.24 is a dis- 
placement shader based on a phased sinusoid in parameter 
space. Those few lines of code are all that are required to cre- 
ate the threads on a light bulb from a simple cylinder. 


Surface shaders 

When light strikes a surface, it frequently bounces around in 
the material of the surface and emerges in some direction 
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Imager shaders 

An imager shader may be invoked by calling Rilmager(). It 
will transform f oating-point pixel color values as supplied by 
the Tenderer after rendering the pixel to the output values of 
a pixel once it is completely rendered. An imager shader takes 
a color on input and places another set of values, of arbitrary' 
meaning, on output. It might be used, ror example, to convert 
RGB output intD a device-dependent format like YIQ or a 
four-color separation. The place of an imager shader in the 
pixel-production pipeline was discussed in Chapter 9. 


Shaders from the Inside Looking Out 

Since shaders an? part of the rendering pipeline, there is no 
question of ' 'calling'' # them in the usual sense from an applica- 
tion using RenderMan. Instead, each shader is plugged into 
a call like RiLightSourceO, referring to the ap- 
by name. Chapter 11 covered the process of 
using existing shiders, considering them from the outside in, 
as it were. From the standpoint of writing shaders, life looks a 
little different. 


the system using 
propriate shader 


Services supporting shading 

A key difference between shaders and standard programming 
"hooks" is that RenderMan goes to great lengths to simplify 
the task of writing shaders, both by an appropriate design and 
specification, and by setting out an extensive array of support 
sendees. Thanks to the rich environment shaders operate in, 
they are often just a few lines of code, and rarely exceed a page 
of text in length. 
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Orthogonal definition 

One aid for shader writers is RenderMaris definition of a ca- 
nonical rendering process. Each shader has a well-defined 
role, and the shaders as a group are functionally indepen- 
dent. A surface shader may be chosen without regard to what 
light sources or volume shaders are in use, and its behavior is 
independent of them. 

Rendering environment 


Taken individually, each shader operates in an environment 
in which the bulk of what normally constitutes shading work 
is already done. When a shader is called, geometric data is ful- 
ly transformed, and a variety of relevant information (the po- 
sition of a surface or light, the direction to the eye, etc.) is im- 
mediately available in a set of global variables, which are pre- 
set every time the shader is called. The problem of resolving 
hidden surfaces is completely managed by the tenderer. 


Special data types 


The shading language provides two special data types, point 
and color, for manipulating geometric and color information. 
The language includes special operators for the point type, and 
the standard programming language operators are able to op- 
erate on both types. 


Varying variables maintained 

As discussed in Chanter 12, anv variables that so into shading 
a surface can be interpolated across the surface, but that fact is 
invisible to the shader itself. The interpolation takes place be- 
hind the scenes; the only difference is that the shader's in- 
stance variables differ from one invocation to another. 


Integration constructs 

In addition to the usual programming language control con- 
structs like for and if-then-else, the RenderMan Shading Lan- 
guage includes special constructs for spatial integration of 
light emerging from light sources and impinging on a surface. 
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f Filtered map access 

Texture maps and other forms of mapped data are accessed 
from shaders as simple function calls, with prefiltered return 
values- Any multichannel value can be stored in a map, ac- 
cessed by a shader and used to control any aspect of shading. 

Function library 

The shading language includes a large library of mathemati- 
cal, color, optical, geometric and noise functions. The com- 
mon shading functions for calculating ambient, diffuse, specu- 
lar, and Phong reflections are also predefined. 

An Example Shader 

We conclude this chapter by dissecting the example shader be- 
low, which reveals some of the features of the shading lan- 
guage. 


1 

ciouds 

c surface shader for a cloudy surface * 


surface 


3 

clouds-' 


4 

fioa 

Kd=.8, 

5 


Ka=.2 } 

6 

i 


7 

float su" 

r ) 

S 

float i, i 

eq; 

9 

color re 

1; 

10 



11 

sum = 0 


12 

tree = A. 

0 

13 

for (i * 0 

i i < 6; 1 = i -r 1) 1 

14 

sum 

= surri + 1 /freq * abs(.5 - noise( freq " P)) ; 

15 

freq 

p 2 * freq; 

16 

) 


17 

refl = Cs 

* sum; 

16 

Ci = retT 

V Ka*ambientO + Kd"diffuse(faceforward(norrnaIize(N},j)) ); 

19 

Oi = 1.0 

; /* Always make the surface opaque "/ 

20 

1 


Listing 13.1 An example shader 
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Overview 

cloudsQ is a surface shader that gives a wispy, cloudlike ap- 
pearance to the shading of a surface, as shown in the bowling 
pin at left. It is called whenever a Tenderer needs the color of 
the light reflecting from a surface at a given point. This shad- 
er can be roughly divided into two sections. The first section, 
through line 17, computes the reflectivity of the surface as a 
summed noise function that scales the input surface reflectivi- 
ty Cs. Line 18 calls the ambientO and diffuseO functions, 
weighting the color values they return by the instance vari- 
ables Ka and Kd, respectively. 

ambientO returns the summed contributions of all ambient 
light sources. diffuseO is passed the normal vector to the sur- 
face, also provided by the Tenderer and reversed, if necessary 
by the function faceforwardO to point toward the viewer. dif- 
fuseO polls all relevant light sources, scaling the light from 
each according to the surface's orientation and summing the 
resulting eyeward reflections into its returned color. 

Resemblance to C 

The most obvious characteristic of this shader is a superficial 
resemblance to a function in the C programming language. 
The shading language is syntactically similar to a subset of C, 
but is tailored to its task. This makes the shading language eas- 
ier to learn, but one must beware of assuming the shading lan- 
guage is C. 


Declaration 

The first distinction between the shading language and C is 
that cloudsQ is not a function or a procedure, but a shader: 
that fact is denoted by the keyword surface preceding the decla- 
ration and indicating that this shader is devoted to computing 
surface reflections. 

Instance variables initialized 

The declared parameters (here, Kd and Ka) of a shader are its 
instance variables. For example, the cloudsQ shader might be 
instanced by the fragment 
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s r 


Rt : !oat Kd = 0.3; 

Ri^urface "clouds' 1 , 

Ri_KD, (RtPointeri&Kd, 

RLNULL }: 

That would give the instance variable Kd the value 3, which 
it would -lave even 7 time this instance of the shader is called. 
Unlike a I function, a shader must specif} 7 default values for 
its parameters (instance variables) because providing values 
when instancing a shader is always optional. In this example 
instance, Ka would have the default value .2. 


Local variables 

cloudsi' has the local variables /, freq, sur '■ and reft, which are 
analogous to C. The shading language supports type float, but 
it also aefnes two vector types: color, giving a light or reflec- 
tance color, and point, giving a point in three-dimensional 
space. 

Global variables 

Four variables appear in cloudsO that are neither local to the 
shader nor instance variables. These global variables are 
shown underlined: L P, Cs and O’. The first three are the 
implicit pa 'ameters of the shader, giving the viewing direc- 
tion l the surface point being shaded (P), the surface normal 
at that point (/V), and the color of the surface expressed as a re- 
flectivity (Cs). All such variables are set before the shader is 
called. The output of the shader, the light emerging from the 
surface, is passed back to the Tenderer in the global variable C/. 


Special operators and functions 


The RenderMan 
both in op 
absQ on line 
diffuseQ on 


Shading Language has predefined extensions 
gators and functions. The functions noiseO and 
14, and faceforwardO, normalizeO, ambientO and 
e 18, are standard in the language. 


lin 


Expressions with vector types 

lerMan Shading Language, arithmetic operations 
r|ts and colors as well as floats. On line 14, the sur- 


In the Rendj< 
work on poi 
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face position point P is multiplied by a scalar before passing it 
into noise(). On line 18, the color returned by diffuse!) is multi- 
plied by the scalar Kd and added to Ka to obtain a color, which 
is then multiplied by the color refl. Since the shading lan- 
guage handles vector operations itself, any operation on color 
is independent of the number of color samples specified by 
RiColorSampIesO. 

Statements and control constructs 

Standard control constructs for looping (while, do, for) and 
conditional execution (if-then-else) are included in the shad- 
ing language, as can be seen on line 13. 

No return value 

The final feature of a shader is that it has no explicit return 
value. It communicates its results by setting one or more glo- 
bal variables. The surface shader is calculating the light leav- 
ing a surface, anc it leaves its result in the global color vari- 
able Ci. Chapter 16 discusses the results expected of the differ- 
ent types of shader. 


Further Reading 

The RenderMan Shading Language is based on the shade 
trees of Rob Cook [COOKS4]. His paper provides much histori- 
cal background and motivation. 
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CHAPTER 1 4 


The RenderMan Shading 
Language II: Description 


r . This chapter details the form of the RenderMan Shad- 
* ing Language. After a quick introduction, the second 
section describes the data types supported: the set of 
global variables that allow shaders to do their work, and the 
form of instance variables. The third section concerns syntax, 
the form of expressions and statements. The fourth and fifth 
sections present three special constructs for gathering light at 
surfaces. 


Defining Shaders and Functions 

Using the data types and syntax described in this chapter, a 
programmer can define both shaders for including in the ren- 
dering process, and user-defined functions for inserting into 
shaders. Shaders may only be invoked by the renderer, func- 
tions only by shaders and other functions. Except as noted, all 
features and constructs of the shading language may be used 
within either. 

A shader is defined by preceding its declaration with one of 
the shading language keywords light, displacement, surface, 
volume, transformation, or imager. 

A function is declared just as in C, by preceding its definition 
with an optional type, either float, color, point, or string. If not 
declared explicitly, the return value of a function is float. 

An important difference between C and the shading language 
is that parameters to functions are passed by reference . In practi- 



•£j 


i 


* H 

* l. 


cal terms, this means that if a function changes the value of a 
parameter, that change persists after the function returns. 
This allows functions to calculate several values and return 
them in its parameters. 

Finally, the shading language forbids recursion, either directly 
or indirectly: no function may call itself, no function it calls 
may call it, etc. 

Functions and shaders are otherwise syntactically identical, ex- 
cept that shaders do not support return values, so the return 
statement tannot be used. Access to shaders is restricted: they 
can be iruoked only from within a RenderMan program, not 
by other shaders or by functions. Functions can be called by 
shaders ard other functions, but cannot be called from out- 
side the shading language. 


Data 


The set of data types in the shading language is small; but in- 
cludes two special types. Except for those two, no aggregate da- 
ta t\y>es are supported. In the following discussion and the re- 
maining chapters, the names of global variables are empha- 
sized bv un ieriirunc; them. 


h.: 




Data tvpes 

The shading 
data types, 
but not mooli: 


float 


string 


point 


language provides for one scalar and two vector 
and also includes the capability to define and use, 
if}', character strings as names. 

The only scalar data type supported by the shading 
language is float. All integer calculations must be 
performed using floating-point variables. 

Character strings are used only for naming such 
external entities as texture maps. They may be ei- 
ther constants or instance variables. 

A point is a vector of three floating-point values; 
such items are usually used to represent positions 
t.nd directions in three-dimensional space. In 
doudsQ, the example in the previous chapter, 
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many of the global variables are points. The point 
P, for example, gives the position of a surface 
point being shaded. 

The individual components of a point are access- 
ed using the special functions xcompO, ycompO, 
zcompO, setxcompO, setycompO and setzcompO, 
discussed in the next chapter. 

color color is another type unique to the shading lan- 

guage, representing either the color and intensity 
of a light, or the reflectivity and opacity of a sur- 
face used to scale a light during reflection and 
transmission. In cioudsi), the color ret'I is used to 
store the reflectance of the surface for modifying 
the light arriving from the light source(s). 

In computer graphics a color is usually represent- 
ed as a triple of values, typically red, green and 
blue, used to drive the three guns of a color moni- 
tor. However, other color spaces do exist. In the 
RenderMan Shading Language, color is an ab- 
stract data type of undefined structure. The pro- 
grammer should make no assumptions about the 
meaning of the values in a color. 

Not only the type but also the size of a color may- 
van'. Renderers supporting the Spectral Color ca- 
pability allow the user to redefine the number of 
elements in a color, as well as their meaning. The 
language is defined so that the programmer 
needn't know the details of the color representa- 
tion if he or she sticks to the standard coior opera- 
tions on color data. 


Coordinate systems 

Both color and point values can be expressed in a variety of co- 
ordinate systems. Colors may be expressed in the standard 
RGB system, but also in a variety of other coordinate systems 
(HSV — hue, saturation and value — and CEE XYZ, for two ex- 
amples), each of which has a name associated with it. Geomet- 
ric coordinates stored in point values can occur in object space. 
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nate spaces. 


camera space and anv other standard or user-definable coordi- 


Coordinate spaces are named as well. 


Within a shader, however, all operations occur in uniform co- 
ordinate spices, one for geometry and one for colors. A shader 
might operate in the geometric object space existing when the 
shader was declared, or world space. Colors might be ex- 
pressed in any of a variety of color spaces. But within a given 
shader, all points will be in the same geometric coordinate 
space, and all colors will be in the same color space, so that the 
programme: need never worn 7 about consistency. Points ex- 
pressed in another space will be automatically converted. 

Constants 

Constants aan be assigned to float variables just as in any pro- 
gramming language. So can point and color values. Syntacti- 
cally, a color expression is of the form 

color soacer.ame,' s\1, \2, v3 

where colof is a kevword in the shading language; \ 7, \2 and 
\3 are am floating-point expressions containing only scalar 
values, anc spacename is an optional string constant giving 
the color space in which (i'J ,\2, v3) is expressed. For example, 

color c = color "hsv" u8, .2, .1 ); 

declares a :olor variable c and initializes it to an HSV value. 
That value will be converted to the common color space be- 
fore storing it into c. 

There are : ive predefined color coordinate systems, listed in 
Table 14.1 together with the meaning of each component of 
color constants in that system, “rgb 11 is the default; if space- 
name is om tted in the expression, u rgb n is assumed. 


Coordinate 
! System 


Meaning 


u rgb' : 

red, green, blue as defined by NTSC; 

"hsv* 

; hue, saturation, value 

“xyz” 

| CIE xyz coordinates 

"xyY 1 

| CIE xv Y coordinates 

“YIQ" 

NTSC coordinates 


Table 14.1 Cdot Spaces in the RenderMan Shading Language 
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point coordinate systems 

Expressions of type point can be specified using a similar syn- 
tax. The relevant coordinate systems for a point are those of 
the rendering process ("object", "world", etc.), plus any named 
coordinate systems the user may already have defined in the 
RenderMan program using RiCoordinateSystemO (see Chapter 
7 for more information). The shading language also defines 
two other coordinate systems, "current", the default, is the 
space in which calculations are being performed (normally 
"camera" or "world", depending on the implementation), 
"shader" is the object space in which the RiSurfaceO call (as op- 
posed to the object being shaded) was made. This allows sever- 
al surfaces, each with its own object space, to share a common 
coordinate system for purposes of shading. 

A point pf can be declared in the shading language and imriai- 
ized to the value (x, v, z ) in the "spacename" coordinate system 
as follows: 

point pt = point “soacename" (x, y, z>; 

(x, y, z) is expressed in the space named by "spacename" and 
transformed into the "current" space. Again, x. y, and z may be 
any scalar expression. If ’’spacename" is omitted, a point con- 
stant is in "shader" space if it appears in the shader parameter 
list, and in the "current" space elsewhere, "shader" space is 
similar to object space: points defined therein are transformed 
by the current transformation as it is defined when the shader 
is instanced. 

Global Variables 

Global variables have a special meaning in the shading lan- 
guage, supplying shaders with information they may use in 
performing their calculations. The Tenderer makes sure those 
values are valid when a shader is called. Since a surface shad- 
er, for example, is concerned with computing the color of 
light reflecting from a surface in a particular direction, it gen- 
erally needs to know the position of that point in 3-dimen- 
sional space and the direction from which it is to calculate a 
reflection. The global point variables P and l respectively, sup- 
ply that information. 



Table 14.2 lists each predefined global variable available to sur- 
face shaders, together with its data type, storage class and a 
summary of its meaning. Different sets of global variables are 
available to other shader types. They appear in Table 14.3. 


Type Name 

Storage Class 

Purpose 

color Q 

j varying/ uniform 

Surface color (input) 

color Cjs 

varying /uniform 

Surface opacity (input) 

point P 

varving 

Surface positron 

point j d^iu 

varying 

Change in position with u 

point dPif\ 

varying 

Change in position with v 

point \j 

varying 

Surface shading norma] 

point V{ 

varving 'uniform 

Surface geometric normal 

float 

varving 

Surface parameters 

float 

varving/ uniform 

Change in u.r across element 

float s r :| 

varying 

Surface texture coordinates 

i 

color L 

varving uniform 

Direction from surface to light source 

color £ 1 

varving uniform 

Light color 

point 

varying 

Direction of ray impinging on 
surface point i often from camera 

color O 

varying 

Color of light from surface (output) j 

color Ot 

varying 

Opacity of surface (output) 

i 

point i E 

uniform 

Position of the camera 


- 


Table 14.2 G/fbfll Variable 5 Available to Surface Shaders 


Surface color and transparency 

Cs and Os represent the current surface color and opacity, re- 
spectively, as declared in RiColorO and RiOpacityO and bound 
to the surface being shaded when it was created. 

Cs and Os are used as filter values. The color of reflected light 
from a surface with surface color Cs under incident light with 
color C[ is often taken to be C[ * Cs . In other words, each com- 
ponent of Cs scales the corresponding component of the in- 
coming light Recording to the absorption of the surface. Os 
has the same effect on light passing through the surface. Nor- 
mally, ever\ ! component of Cs and Os lies in the range [0,1]. 
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dPdv 


Figure 14.1 Surface vosi::on, normal , and parametric derivatives 


Surface position and change 

The point value P represents the position of the point being 
shaded in world space, and Sg is the geometric normal vec- 
tor, perpendicular to the surface, at that point. The shading 
normal vector N is by default equal to .Vg, but may be different 
for shading purposes. If a displacement shader changes the 
surface normal, it usually works on N and leaves fVg alone. 

Parameter space 

The floating-point values u and v give the position of the cur- 
rent point on the current surface in parameter space. The 
points dPdu and dPdv are parametric derivatives, giving the 
derivative of surface position P with respect to u and v, respec- 
tively. The surface normal Ng is defined to be the cross-prod- 
uct of these two vectors, u and v always range between exactlv 
0 and 1 on all surfaces except polygons. 

Figure 14.1 illustrates P, Ng, dPdu and dPdv. The normal vec- 
tor Ng is the cross product of dPdu and dPdv by definition. 

Texture space 

The floating-point values s and t give the texture-space coordi- 
nates of the current point on the surface. They may be used to 
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index into textures or bump maps (see the section on built-in 
functions, below), etc. for modulating surface properties coher- 
ently. They may also be used as input to any function in two 
dimensions for varying the appearance of the surface. 

s and t are equal to u and v, unless vertex variables or RiTex- 
tureCoordimatesO changed the texture space of the primitive 
being shaded. By default, though, all quadrics, patches and 
patch meshes exactly cover the texture range [0,1]. 

Reflection variables 

A surface shader reports its reflected light back by setting the 


global colo 


variable O', and reports in color 0/ the extent to 


which it blocks light from behind the surface. The default val- 
ues of both O and Oi are undefined. Consequently, all shaders 
must take care to set them explicitly. cloudsQ in Chapter 13 al- 
ways set C'i to 1.0, producing an opaque surface with varia- 
tions only in reflected color O'. 


Light variables 


The color C 
given point 


If 

the distance 


arriving. 


gives the color of light arriving at the surface at a 
and the point L gives the direction in which it is 
the light source has a position, then L’s length is 
between the light point and the surface point. 

While the variables above are always defined when a shader 
is called, L ind Cl are redefined for each light source. Since a 
surface shader is called only once at each surface point, but 
there may te light from many sources impinging on that sur- 
face, the shading language provides the illuminance construct, 
described in the fourth section of this chapter. In concept, it 
"loops" ovet all light sources, setting L and C[ once for each 
light source. (This may not be strictly true for all Tenderers.) 

Camera and surface position 

When a shaler is called, the point £ is set to the position of 
the camera in world space. Frequently the reflection being cal- 
culated is toward the camera, so that the incident direction 
l = P-E. However, in the context of a ray tracer, rays may be cal- 
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culated in any direction, so that one should not assume that 
this equality always holds. Consequently, E should be used 
rarely if ever by a surface shader. 

Surface derivatives 

Two other global variables are provided in support of surface 
elements. Some Tenderers operate by dividing surfaces into 
pieces small enough to be rendered with a single color. Sur- 
face elements are typically smaller than a pixel as seen in the 
image, in which case flatness of either color or geomerry is 
usually not discernible. 

Small size notwithstanding, some shaders may find it handy 
to know how large a surface element is being shaded. For 
these purposes, the global floating-point values du and dv 
give the change in parametric surface parameters u and v 
across the element. Of course this assumes that the bound- 
aries of an element are rectangular in parameter space. 

The names du and dv hint at a third characteristic of surface el- 
ements: they are usually small enough that the absolute 
change in u and v across the element mimic the surface's de- 
rivatives at the current point. In fact, the following relation- 
ship holds: if the surface location P( u, v ) is P at parameter loca- 
tion (u, v ), then 

Piu-^du, v) = Piu, v) + dPdu * du 

and 

P{u, v-cv ) = P(u, v ) + dPdv * dv 

Global variables in other shaders 

Table 14.3 lists the complete set of global variables that are 
part of the RenderMan Shading Language. Not all of them are 
available within all shaders, however, so the table also indi- 
cates what variables are available inside which types of shad- 
er. In a cell of the table, 'R' indicates that a shader of the given 
type may read the variable, and / W / indicates that it may write 
values to that variable. 

When a shader of a given type is called, the Tenderer guaran- 
tees the validity of all of the 'R' global variables listed under 
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Type 

Name 

■ 

Surface 

Light 

Displ. Transform Volume Imager 

color 

c| 

R 


1 

color 

3 

R 


i 

point 

o ! R 

, R 

RW RW i R 1 R 

point 

d'Fdu 

R 

Rt 

R 

point 

dPbv j R 

R+ 

R 

point 

N R 

R T 

RW I RW | 

point 

point 

M R 

E\ 

Rt 

R i 

R 

1 


float cl,i 

A | R R+ 1 R | i 

* ’ 

float s r 

*1 

-1- 

point L 

color C 

R* R* 

R" RW- 

point I 

R R 

color Q 

color 

RW RW RW 

RW 1 RW RW 

point £ 

R R R 

float 

R R 


* msidc solar illuminate ) or illuminance > 

" only 5f;?5?Pi'V m area light sources 


Table 14.3 Gibhv Variables in the RenderMan Shading Language 

that type in Table 14.2. A shader of a particular type returns a 
value by setdng one or more of the TV' variables, and cannot 
moaifv anv others. 


instance variables 

if global variables are effectively the parameters of a single call 
of a shader, instance variables are the parameters of an in- 
stance of a shader. A single light source shader, for example, 
can be instanced a number of times as distinct light sources 
differing in position, color, etc. 

Instance variables are declared for a shader as if they were pa- 
rameters to the shader routine. In cloudsO, the instance vari- 
ables are Ka and Kd, representing the weight accorded to ambi- 
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ent and diffuse reflections from the surface. When the shader 
:s instanced, the application gives them values by passing to- 
ken-value pairs to RiSurfaceO. Those values are passed to the 
^hader every time the instance is invoked. They cannot be 
(fhanged after the instance is created. 


Default values 

Instance variables differ from procedure parameters in one 
ijmportant respect. They must be assigned default values 
•vyhen they are declared. In cloudsQ, Ka has the default value 
.B and Kd is .2. This constraint makes all instance variables op- 
tional when instancing the shader; any variable whose value 
iS not specified receives the default. 


Local variables 

Shaders may have local variables as well as instance variables 
and global variables. They may be declared only at the begin- 
riing of a shader and may be float, point, or color, but not string. 


Storage classes 

The float, point, and color data types may be declared under 
ty/o different storage classes, uniform and varying. A uniform 
instance variable is assumed to be constant over a surface, so 
it has the same value every time an instance of a shader is 
called. A varying instance variable can differ for each point on 
the surface. It mav or mav not actuallv be different each time 
an instance of a shader is called. Declaring a variable to be uni- 
form may allow the shader to be executed more efficiently: 
apv expressions involving only uniform variables need only 
b^ evaluated once, when the shader is instanced. By default, 
instance variables are uniform and local variables are varying. 


Syntax 

The syntax of the RenderMan Shading language is like C in 
mpny respects, but is tailored to the job of expressing shading 
calculations. 
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Expressions 

The shading language supports both arithmetic and logical ex- 
pressions on float, point, and color values, adding two special 
operators fir points and colors. Table 14.4 gives the set of oper- 
ators, their precedence and purpose. 


Operation 

Associativity 

Function 

0 


left 

expression grouping 



right 

unary arithmetic logical negation j 



left 

dot product 

* / 


left 

multiplication, division 

A 


left 

cross product 



left 

addition, subtraction 

A 

A 

M 

II 

V 

V 


left 

arithmetic comparison 



left 

equal, not equal 

6zk 

1 

left 

logical AND 

1 1 

left 

logical OR 

? : 

right 

conditional expression 

- 

right 

assignment 


Table 14.4 Operators in the Shading Language 


Operators 

Both arithmetic and relational operators have the same mean- 
ing for floating-point values in the RenderMan Shading Lan- 
guage as thev do in C. 

Arithmetic on special types 

When the arithmetic operators V, and are used on 

two point values or two color values, they are applied to each 
component of the two individually, forming a like-typed re- 
sult. To be consistent with the definition of color as an ab- 
stract type, they are illegal between a point and a color even 
though the two types often have the same number of compo- 
nents. 

When an arithmetic operation is performed between a float 
and a point or a float and a color, the scalar is promoted by du- 
plicating its value in each component of the vector. This is 
equivalent to performing the operation between the float and 
each component in turn. 
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Comparison of special types 

The result of a comparison is always a single Boolean value, 
even if the operands include a point or a color. In fact, the 
only relational operators allowed between two points or two 
colors are '==' and If a float is compared to a point or a col- 
or, it is promoted just as for arithmetic operations. 

Dot product 

In C, the operator is used to access an element of a struc- 
ture, but there are no structured data types in the shading lan- 
guage. Here, the operator is a dot product, taking two point 
operands and forming a float by multiplying corresponding el- 
ements of the two points, then summing the products. 

Meaning of dot product 

The dot product is a simple way of measuring the angie be- 
tween two vectors. If |A| is defined as the Euclidean length of 
vector A, then for vectors A and B, 

A.B = |A||Blcos0 

where 9 is the angle between A and B. If A and B have been 
normalized such that |Aj = |B| = 1, then A.B = cos0. 

Dot product operands 

The dot product takes either two points or two colors as oper- 
ands, never one point and one color. If one of the operands, 
but not both, is a float, it is promoted to the appropriate type 
by duplicating its value in all elements of the type. The dot 
product of two color values is allowed. 

Cross product 

The cross-product operator //v applies to point values and 
forms a point result, unlike the dot product. If A and B are vec- 
tors represented by a point, then A A B is a vector perpendicular 
to both A and B. The length of A A B is 

|A A B| = |A||B|sin0 

where 0 is the angle between A and B. 
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A leaning of cross product 


The cros$ 
surface 
the surfa 


at 


expressec 
uct of the 
er words, 


N 


product is commonly used to find the normal to a 
a point, given two nonparallel vectors tangent to 
:e at that point. The geometric surface normal vector 
in the global variable Ng is defined as the cross prod- 
parametric derivative vectors dPdu and dPdv. In oth- 


; ? e dPdu A dPdy. 


Cross product operands 

As with the dot product, the cross product of a point and a 
float is performed by promoting the latter to a point by setting 
all compcnents of the point to that value. Doing so doesn't 
usualiv make sense, however. 


Statements 

In addition to the assignment statements expected of any alge- 
braic programming language, the shading language supports 


statement [grouping using the delimiters T and 
with the control constructs for which thev are most useful 


if-then-else 


together 


Both conditional execution and looping are controlled by bool- 
ean expressions. These typically result from a binary compari- 
son between two values. In C, any arithmetic value can be 
used to form a boolean expression; if the value is nonzero, 
the boolean is true. In the shading language, however, it is il- 
legal to use a float, point or color value where a boolean ex- 
pression is * 


while 


expected. 

One of two alternative statements can be chosen 
for execution with the usual if-then-else construct: 

if boolean expression } statement [ else statement ] 
where statement is either a single statement or a 
series of statements between the delimiters '{' and 
The else clause is optional. 

k statement can be executed repeatedly with the 
vhile construct: 

while ( boolean expression ) statement 
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The expression is tested before statement is first 
executed, and statement is executed repeatedly as 
long as the expression is true. 

for The shading language includes the C for state- 

ment: 

for ( expr; boolean_expression; expn statement 

cloudsQ shows that the for construct in the shad- 
ing language parallels the C version: the first expr 
is executed onlv once, before statement is first exe- 
cuted; boolean_expression is evaluated before ev- 
ery execution of statement; and the second expr is 
executed after statement. Since an assignment 
statement is accepted as an expr, the two exprs can 
be, and most commonly are, used to initialire and 
increment loop variables. 

break A for or while loop can be terminated regardless of 

the state of its controlling boolean by using 

break ;nj 

with a constant value n to specify that n levels of 
nested loops should, be terminated, beginning 
with the innermost, n is optional, defaulting to 1, 
terminating the innermost enclosing loop. 

continue A loop can also be restarted with the continue con- 
struct, 

continue [n] 

which redirects execution to the bottom of the nth 
nested loop. If the loop is a for construct, this is ef- 
fectively a branch to the increment expr. Again, n 
must be a constant and its default is 1, the inner- 
most loop. 

return A function (not a shader) can be terminated at any 
time using 

return expr 

where expr will be the value returned from the 
function, and is cast to the expected return type if 
possible, expr may be omitted. 
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I 

| illuminance 

One of the novel constructs of the RenderMan Shading Lan- 
guage is illuminance. The basic idea is to give surface shaders a 
way of collecting samples of all the light arriving at a surface 
at the point being shaded. 

Figure 14.2 shows the expected configuration. Light reflected 
in the direction _/ may be influenced by light striking the sur- 
face from anywhere in the incident cone W (which in this 
case is a hemisphere;. For a very diffuse surface, light striking 
from &nywhetre above the surface can be reflected toward the 
camera, so IVj opens at a 180 c angle in this case. The first job of 
the illuminance construct is to limit the attention of the sur- 
face shader tolthe appropriate direction. 

illuminance The svntax of illuminance is 

illuminance' position [, axis, angle.' statement 
pqsirion is the only required argument, a point giv- 
ing the position of the apex of the incident cone. It 
is usual!}* P for a surface shader (see Figure 14.2 
foij clarification), axis is a point, a vector giving the 
center of the cone as a direction from position, an- 
gle is a float giving the angle between a side of the 
coijie and the axis, in radians, so the cone is 
2 * angle radians wide. No samples will be taken 
outside this cone. 

If axis and angle are omitted, light contributions 
are summed over the entire sphere centered at po- 
sition, The usefulness of this default is limited be- 
cause surfaces are normally not iUuminated by 
lights behind them, but the hemisphere of illumi- 
nance needed to do that is impossible to define in 
the absence of an axis. If that behavior is desired, 
axis would be the surface normal and angle would 
be Ff 1/2. If angle is 0, the cone is infinitesimally 
thin, a single ray in fact, and only light coming in 
from exactly that direction is used for shading the 
surface. A mirror would be the surface most likely 
to use such an angle . A specular surface might use 
a narrow angle, and an axis obtained by reflecting _/ 
about the surface normal. 
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distant light 


point light 

(used) 




distant light 
(used) 


Figure 14.2 Model of incident light served by the illuminance construct 


For each source of illumination within the inci- 
dent cone, statement is executed once with C set 
to the arriving light and L the direction toward 
the source. In most cases the shader will use both 
C[ and L to calculate the color reflected toward the 
eye from that direction. 

illuminance statements cannot be nested. In other 
words, statement cannot include another illumi- 
nance statement. 

How illuminance works 

The illuminance construct is designed to support different ren- 
dering approaches. For simpler shading models, the only im- 
portant elements in illuminating a surface are light sources. 
Renaerers operating under such models will usually sample 
only the light sources, executing the illuminance statement 
once for each light source within the cone. With two excep- 
tions, this reduces the illuminance construct to a simple loop 
over all relevant light sources. One exception is ambient light 


illuminance 
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sources, vvhic 


have no direction. Their contribution must be 


handled separately by having the shader call the built-in func- 
tion ambientO. The other exception is an area light source, 
which may be treated as if it were many individual point light 
sources. 


Sampling reflections 

More sophisticated rendering approaches (for example, rav- 
tracing and radiosip methods) may illuminate a surface with 
light reflected from other surfaces as well as a light from light 
sources. Rays are cast from P to determine the light O arriv- 
ing from diffjeren: directions L, regardless of whether that 
light was emitted by a light source or reflected from a surface. 
All this is transparent to the shader that uses an illuminance 
statement. 


Ray tracing and illuminance 

' 

Fans of rendering by ray tracing may have recognized by now 
the resemblance between sampling under illuminance and ray 
tracing. In ray tracing, rays wouid be cast from P within the il- 
luminance cone 1\MTITTED80J. The reflection at the first sur- 
face struck by each ray is calculated recursively, then used in 
the reflection at the original surface. Rays would normally be 
cast toward iig'it sources within the cone. 

The shading language supports ray tracing implicitly by ignor- 
ing the difference between light coming in from light sources 
and light from surfaces. (This is why a surface shader should 
always use / jas the view direction rather than (P— f) even 
though they are equivalent when viewing a surface from the 
camera.) Shaders pass the problem of deriving the incoming 
light back to the Tenderer by using the illuminance construct. 
Not all Tenderers support this generality, however. 

illuminance and radiosity 

Another popular shading technique calculates diffuse reflec- 
tion using a complete analysis of the distribution of light ener- 
gy (radiosity) in a scene [GORAL84]. A radiosity-based Tender- 
er may return the results of the radiosity calculation in the dif- 
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fuse() function, but the illuminance statement could easily 
serve the same purpose. The Tenderer might present the arriv- 
ing radiosity in a variety of directions as iterations of the illu- 
minance statement 

illuminance and integration 

The illuminance construct is really meant to model the integra- 
tion of incoming light over a specified cone. There are ways to 
accurately compute the integral, and that's what illuminance 
does, at least in principle. However, a given implementation 
may take short cuts. Even within a given implementation 
there may exist controls over the accuracy of the approxima- 
tion. No approximations in the Tenderer, though, should af- 
fect the way an illuminance statement is used by the shader. 


illuminate and solar 

The illuminance construct allows surface shaders to integrate 
the light impinging on a surface over a finite cone. Two simi- 
lar constructs exist for light sources to denote the distribution 
of light emerging from the source. Both of them are specified 
over a cone, and the statements within may be executed for 
any direction inside the cone. 

Model of light emission 

Many light sources are directional, casting all their light in 
one direction and none in others. The classic example of this 
behavior is the sun as seen from the earth, where rays are es- 
sentially parallel. At the opposite extreme are so-called point 
lights, which emit light uniformly in all directions from a sin- 
gle point. 

Since the illuminance construct of surface shaders is executed 
once for each directional sample, it would help the underly- 
ing system to know' what light sources are relevant in a partic- 
ular direction: there's no sense evaluating a light source shad- 
er if it's pointed in the wrong direction. The solar and illumi- 
nate constructs for light source shaders provide that informa- 
tion, declaring a solid cone of emission such that surface 
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points outside the 
sidered to be in the 


cone of emission of a light source are con- 
dark. 


The illumination 
to the illuminance 
specified in the heja 
function of direcqo 
were called repeat 
fact, the body is 
from within the cork 


qonstructs are declared in a manner similar 
construct. They are driven by s solid cone 
aer. The body specifies the cast light as a 
n within the cone, as though the body 
:< 'dly to spread light throughout the cone. In 
oplv executed when a surface requires light 


Though the illumi|n 
pearance of loopin 
coroutines operatic 
construct: the rend 
provided by the tw|o 
each cone is within 


ation constructs have the superficial ap- 
constructs, they are more in the nature of 
: in conjunction with the illuminance 
;rer calculates the intersection of the cones 


The difference be 
that one includes a 
doesn't (infinitely 
Since in both caseg 
they cover both di 
with and without pi 


Each body is executed only if the apex of 
1 he other cone. 


!v\ 


•een the two illumination constructs is 
position for the light source and the other 
distant light sources have no position), 
the solid cone is optional, between them 
ectiona! and non-directional light sources, 
dsition. 


illuminate The illuminate construct has the syntax 

illuminate position axis, angle j j statement 
statement is a statement in the Renderlvlan Shad- 
ing Language, position and axis are any valid point 
ions, while angle must be a float expres- 
sion. The value of position gives the location of 
the apex of the cone, and axis specifies the direc- 
the center of the cone, angle is the angle be- 
tween the center of the cone and its outside in ra- 
dians, so that an angle of PI/2 covers a hemi- 
sphere. If axis and angle are omitted, the light 
emits over the entire sphere centered at position. 

Within itatement, L is set to the vector from posi- 
tion to a! surface point in three-dimensional space. 
The length of L is the distance between the light 
source Position and the surface point. The light 
source shader should set O to the color and inten- 
sity of the light emerging from the source and ar- 
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position P 



surface of 
area light 


not illuminated 


Figure 14.3 illuminate on an area light source 


riving at the surface. Many shaders wil 1 diminish 
the intensity of the light with distance from the 
surface. 


A point light source 

A point light source is given in terms of the illuminate con- 
struct by 


illuminatei P ) 

Ci = (Intensity * lightcoior) /(L.L); 


P is the position of the light source, intensity the relative in- 
tensity of the source and lightcoior its color. (Presumably the 
latter two are instance variables). Since L is preset to the vec- 
tor from P to the point being illuminated., the dot product LL 
gives the square of that distance and dividing by the result im- 
plements an inverse-square law falloff. 


An area light source 

The illuminate construct makes it easy to define an area light 
source. Inside an area light source, the global value P is set by 
the Tenderer to a point on the surface of the geometric primi- 
tive that describes the area light, and most standard surface 
variables are defined. Figure 14.3 shows the situation. 
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The following 
source: 

illuminate* 

CU 


statement implements a simple area light 


P, N. Pl/2 ) 

(intensity * lightcolor) / (L.L); 


solar 


The axis N and angle PI/2 allow the source to cast light over 
the hemisphere centered at P. The assignment to O distrib- 
utes the emitted light uniformly over the hemisphere with- 
out regard to angle. 

The solar construct restricts illumination to a 
rang: of directions without specifying a position 
for tie source. At two extremes of behavior, it en- 
compasses distant light sources, which cast light 
in cniy one direction, and starlight in space, 
which comes from all around and doesn't van 1 
with different positions. 


The 


solar construct appears as: 
solan iaxis, angle] ) statement 


axis, angle and statement have the saine meaning 
as in the illuminate construct: statement is execut- 
ed (light is cast) only for directions within angle ra- 
dians from the direction vector given by axis. If 
the arguments are omitted, statement is always ex- 
ecuted (light may be emitted in any direction). 
Within statement, Ps is set to the position of the 
surface point being shaded. This contrasts with L 
in illuminate, since a solar source has no position 
and L runs between the surface and light source 
positions. 

A light source representing a distant light source such as the 

sun is easy to specify: 


solan D, 0 ) 

Cl = int 


?r>sity * lightcolor; 



C[ is nonzero only in directions matching the direction D of 


the light source. 


A skylight shader 


A skylight source is almost as easy, and serves as an example 
of the solar construct. In the earth's atmosphere, light from 




the sun illuminates objects both directly (directionally, as in 
the distant source above) and indirectly by means of refraction 
and scattering in the atmosphere. To a first approximation, 
this indirect light can be treated as a uniformly-illuminated 
hemisphere, and the light arriving at a surface can be treated 
as a summation of all the light from the hemisphere toward 
the surface. 

The soiar statement below implements a simple version of 
skylight: 

point D = point "world" (0, -1 , 0); 
solan. D, P!/2 i 

C! = intensity ” ligntcolor; 

It assumes that the surface of the world is in the x,z plane in 
world space, so that y is up. It takes light from the "sky," the 
hemisphere centered on the y axis and opening to negative y. 
For a surface shader that uses illuminance to sum incoming 
light over a broad incident cone, the intensity of sky light will 
be greatest for surfaces facing the zenith, and fall off to 0 in the 
opposite direction. 

In reality, for any angle within the skv light hemisphere, both 
the color and the brightness of the light depend in a complex 
way on the angle's nearness to the sun and the horizon. But 
that is left as an exercise for the reader. 
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CHAPTER 1 5 

The RenderMan Shading 
Language III: Tools 


r The RenderMan Shading Language specifies numer- 
0 ous functions that shaders and other functions can 
call — tools of the shading trade, vou misht sav. That 
functionality is described in this chapter. 


Mathematical Functions 

The mathematical functions supported by the shading lan- 
guage are summarized in Table 15.1. Most of them are generic 
scalar mathematical functions, for which no further explana- 
tion is necessary. All arguments are floating-point expressions 
and all functions return float values. Angles are expressed in 
radians. 

There are other mathematical functions, described below, that 
aren't limited to float values but can also take, as well as re- 
turn, point or color values. Unlike the case in many program- 
ming languages, the same function name is used for all three 
cases, so that, for example, any type of expression can be inter- 
polated by the splineO function. Needless to say, all arguments 
must be the same type in a given call. The functions below are 
also more exotic than those in Table 15.1 in terms of their ca- 
pabilities. 


splinefvalue, rl , f2...fn, ini) 

The splineO function returns a point on a curve fitted to a 
number of values using a Catmull-Rom interpoiatory spline. 
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; Name 


, Returns 

sin(a) 


sine of angle a, a float expressed in radians 

asin(a) 


arcsine of angle a 

cos(a) 


cosine of angle a, expressed in radians 

acosiai 


arccosine of angle a 

tan(a) 


tangent of angle a, expressed in radians 

atan(a) 


arctangent of a 

atan'.v,x) 


arctangent of (y/x) 

float PI 


predefined float value o: PI 

radians ;2 


degree-to-radian conversion 

degrees a 


radian-to-aegree conversion 

1 sqrt(x 


square root of x 

pow(x.y) 


x v of x and \ 

expix 


e* for x 

logtxj 


natural logarithm of x 

modia, bi 


a modulo b 

abs(x 


absolute value of x 

signlx 

i 

t 1 or -1, depending on sign of x 

mtnia.b 

! 

minimum, of a and b 

max(a,b 


maximum of a and b 

damp^mimma 


a clamped to the range [min, max) 

ceiiixj 


smallest integer greater than or equal to x 

floor(x> 


largest integer less than or equal to x 

rounds 


closest integer to x 

stepfmin. val) 


0 if val < min ; ] if val> max 

smoothstep.min 

. max, \al) 

0 if val < min ; 1 if val> max; otherwise, a 


smooth Hermite interpolation between 0 and 1 


Table 15.1 Shading Language Scalar Math Functions (all arguments and return 
values are type float,- 1 


value should lie between 0 and 1. If it is 0, f2 is returned; if it is 
1, fn is returned. Otherwise, a point on the fitted curve is re- 
turned. The curve passes through all the points C.../h. fl and 
fnl are used to determine the direction of the curve at its end- 
points: at f2 r the curve's tangent is ( f3-fl ), and at fn, (fn 7-/(n-l)). 
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The arguments to splineO may be float, point or color expres- 
sions, but all arguments must be of the same type. The return 
type matches that type. 


Derivative functions 

Surface shaders frequently can make use of various deriva- 
tives on the surface, typically expressed in the parameter space 
of the surface. 


Du: expr ) 

Dvi expr ) 

Within a surface, displacement or deformation shader, or a 
light source shader operating on an area light source, Du() 
and Dv() compute the parametric derivative of the expression 
expr with respect :o the u and v parameters of the underlying 
surface. 

It only makes sense to take the derivative of expressions that 
depend on varying variables: the derivatives of uniform ex- 
pressions are always 0. 


The derivative of a variable with respect to variables other 
than u and v may be taken using DerivQ. 


Derivf num, denom ) 

Deriv() computes the derivative of expression num with re- 
spect to denom. The arguments may be of arbitrary but identi- 
cal types. The result (of the same type) is calculated using the 
rule: 


Deri v(num, denom) = - Du(n u - m) + Dv( :?.^L. 

D u(denom) Dv(denom) 

As with Du() and DvQ, DerivQ is only useful when num and 
denom are varying expressions. 
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Noise 


noise(val) 
float val; 


noise(u, v) 
float u, v; 

noise(ptl 
point pt; 

The noise() function computes either a 1-, 2- or 5-dimensional 
noise function, depending on the number and type of its argu- 
ments. It returns a float value between 0 and 1 by default, but 
point and color values can be obtained, as in 
p = point noise ... ); 

and 


c = color noise ... ); 

noiseO is based on random-number generation, but it is guar- 
anteed to be consistent from one frame to another. Any ap- 
pearance parameters based on noiseO will be stable in an ani- 
mation as long as the parameters to noiseO are stable. 


A word about magic 

Some of the functions above might seem problematic to im- 
plement. Just how, for example, do DuO and Dv() know the 
derivative of, no: just varying variables, but expressions as well? 
How does splineO know what type of data to return? 

The existence of these functions is a benefit of special-purpose 
programming language design. The compiler for the shading 
ianguage knows how varying variables change over a surface, 
and can approximate the derivative of a variable using its 
change over a surface element. The compiler knows a priori 
about the predefined data types, and can determine the appro- 
priate version of splineO from the context. 

These kinds Of functions work well enough that it is not 
worth discussing their internals. However, there are small 
but significant inherent dangers associated with some of the 
functions to follow. These pitfalls will be highlighted as they 
arise. 
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Shading, Coloring and Lighting Functions 

The functions described next aid the process of writing surface 
shaders by implementing some common shading algorithms. 
Each one calculates a basic type of reflection over all light 
sources, summing them into a net reflection. Thev allow a 
surface shader to break down the process of shading a point in- 
to two parts. The first part modifies the contribution of each 
light source according to the orientation of the surface with re- 
spect to the light; ;he second part factors in the color of the sur- 
face after summing the lights. 

None of the functions below concern themselves with the col- 
or of the surface. In other words, the color is returned as if the 
surface were completely white. The calling shader must de- 
cide what to do with that value: whether to multiply it by the 
surface color Cs to color the reflection, or to look up the reflec- 
tance in a texture map, or whatever. The shading functions 
concern themselves only with geometry and light source char- 
acteristics. Any other property of the surface must be attended 
to separately. 

These functions are intended to aid in developing a variety of 
shaders, and are not meant to be universal. Specifically, they 
are inappropriate if the reflectivity of a surface varies with in- 
cident angle, since the returned value represents a simple 
summation of light from all incident directions. 


Ambient illumination 


color ambientO 

The ambientO function sums the contributions of all ambient 
light sources in a scene and returns it as a color. An ambient 
light source is one with no illuminance or solar statement. (See 
Chapter 14 for a discussion of these constructs.) 

Most surface shaders will multiply the return value of ambi- 
entO by the color of the surface (for example, Cs or a texture 
value) to get the ambient contribution to reflected color. 
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Diffuse illumination 


color diffuse, norm 
point nornss; 

diffused calculates diffuse reflection for a given surface nor- 
mal, given by norm . diffuseO sums the diffuse reflection for all 
light sources as follows: 

color C = 0, 

point ummorrr = normalizemorm); 
illuminance 5 P. unitnorm , Pl/21 

C -= Cp normalizefLi.uniTnorm ; 
return, C * * 

Since diffuseO uses the illuminanceQ construct, the incoming 
light Cl may arise from object reflections as well as light- 
source emissions, depending on the renderer. Radiositv-based 
Tenderers will do much of their work in the guise of the dif- 
fuseO function. 


Phong illumination 


color phongnorrk, eve, size) 
point norm, §ve; 
float size; 

Like diffuseO; phongO sums the contribution of all light sourc- 
es over a surface. The Phong shading model assumes that re- 
flections are greatest in the "mirror" direction R, opposite the 
eye vector with respect to the surface normal, falling off rapid- 
ly from RT The exponent is given by the size parameter: the 
greater the value of size , the sharper a highlight appears, eye 
is the direction of the viewpoint from the surface (normally 
f), and norm is the "normal" about which the eye is reflected 
* 

* Note on typeface conventions: In this discussion, R, L, N, I, and H are 
vectors, and are shown in boldface. Of these, L, N and I are available in 
the Render.Man Shading Language in the global variables i, N, and L 
This is represented by underlining the boldface type as in L, N and I. 
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to obtain R. norm is usually N. For each light source, phongO 
scales the incoming light by 



raising the cosine of the angle between R and L to the power 
size. 


Specular reflection 

The specular shading model is similar to the Phong mode! in 
basing its falloff on the angle between two vectors. Whereas 
the Phong model uses the angle between light-source direc- 
tion L and the mirror direction R, the specular shading model 
uses the angle between the normal vector N and the 
"halfway" vector H, which points exactly between L and the 
incident direction I. 


color specular! norm. eve. 'ougnness 
point norm, eve; 
float roughness; 

specularO accumulates specular reflections in the direction 
eye off a surface with normal norm. For a given light source, 
the reflection falls off as follows: the direction vector H half- 
way between L and eye is compared to norm. The cosine of 
the angle between H and norm is raised to the rower 
1 / roughness. The light source color C[ is scaled by the result. 
The surface color must be factored in elsewhere. specuiarO 
scales the contribution of each incoming light source by 


c = 


norm. H ^ ( 7 /roughness) 

I norm I I H I J 


Figure 15.1 shows the difference between Phong and specular 
reflection for a distant light source in front of and below the 
scene, and one behind and above it. At the top are four 
spheres using specularO with roughness values of (from left 
to right) 0.4, 0.2, 0.1 and 0.05; the bottom four use phongO with 
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**** * 



f MruifiTi ■ t>s. Phong(bottom) reflectior, 


size set to if, 10, 20 and 40. In addition to providing a subjec- 
tively more credible highlight, the specular model avoids the 
sudden discontinuin in brightness visible in the bottom left 
sphere. That transition occurs because the Phong model gives 
a bright reflection even for points near the "horizon" of the 
sphere with, respect to the light source. As a result, the cutoff 
occurring where the surface turns away from the light seems 
abrupt. 


Ray fracing 

As discussed in the last chapter, the illuminance construct col- 
lects samples of light falling at surface position P in a variety 
of directions. This is equivalent to invoking a ray tracer in 
each direction. This same capability can be accessed directly us- 
ing the built-in function traceO: 
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color trace( location, direction ) 
point location, direction; 

traceO determines the color of light incident on surface point 
location , from the direction direction. Implementations may 
vary, but traceO is equivalent to the illuminance statement 

Ci = 0; 

illuminance ( location, direction, 0 ) 

Ci G; 


Map Access Functions 

Chapter 12 discussed how to apply maps to surfaces. This sec- 
tion describes the support within the shading language for us- 
ing those maps during the shading process. 

There are four basic types of map: texture, environment, shad- 
ow and bump maps. Their names indicate their nominal pur- 
poses. However, no rule dictates how the data from a map is 
used. A map may be viewed as a multi-valued function in 
(usually) tw'o dimensions, where the two dimensions cover 
the surface. This makes mapping the natural extension of ver- 
tex-value interpolation for modulating arbitrary properties of 
a surface across its extent. With a little thought, mapping can 
become a powerful tool for creative shading. 

Maps and channels 

As discussed in Chapter 12, a map is a digital representation of 
a function in either two or three dimensions. Most maps are 
defined with a number of channels; a color texture map, for 
example, may have separate channels for red, green, blue and 
sometimes opacity (alpha). Accessing a point on the map re- 
turns a subset of the channel values at the specified location. 

Map types 

The RenderMan Interface describes maps of four kinds. Tex- 
ture maps are generally used to modulate the reflectivity of 
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surfaces. Bump maps are used to specif}* small variations in 
the shading normal of a surface, giving it the appearance of 
roughness with no change in geometry. Both texture and 
bump maps are indexed bv relative surface location. Environ- 
ment map< depict the world as viewed from an object, and are 
used for mirror reflections. They are indexed by direction of 
reflection irom a surface. A shadow map contains informa- 
tion about now a light source is obscured by objects in a scene. 
A shadow map is indexed by the location of a point in three- 
dimensional space. 


Mapping w notions 


Each of these four nqoes has its own map access function. The 
o the map access functions are divided into three 
texture-map index function illustrates. 


arguments 
groups. The 


texture name 


name is a si: 


hanneP textcoords oaramereriist ' 

ring, the name of a texture mar file as created bv 


RiMakeTexti re(), discussed in Chapter 12. channel selects a set 
of the map'- channel(s) to be accessed. The channel specifica- 


of an RGB A 

textcoords is 
coordinates, 
tion on the mb 


tion is optimal, but if present it must include the square 
. it i 
number of tl 


brackets, it \s a small non-negative integer constant giving the 


the first channel accessed. If an RGB texture map is 
to be accessed in all three channels, channel may be given as 0, 
but that is the default if channel is omitted. The alpha channel 
texture map has a channel of 3. 


not an expression but an optional set of texture 
i there are two coordinates, they specify a loca- 
te access. The call 


texture 'amap" [1], sloe, tloc. ... ); 

samples the texture map "amap" at location (sloe, tloc) begin- 
ning with cha me! 1. If there are eight coordinates, as in 

texturefmap2' ! / si ,t1 , s2,t 2, $3,t3, s4,t4, ... ); 

the map is accessed from channel 0 over the quadrilateral 
specified by the four points in texture space. Texture values 
will be filtered to produce the value returned. If 
ordinates are omitted, the texture map is access- 


over that area 
the texture co 


ed at location (s, ?), the current global texture coordinates. 


320 


Chapter 15: The RenderMan Shading Language 111: Tools 




E 


The parameterlisi at the end of a map access is a series of to- 
ken-value pairs. The main idea is to use them to control the 
quality of filtering done in the access, and there are four stan- 
dard parameters that exert this control. However, future ver- 
sions of the interface specification and other implementations 

mav extend this list. 

✓ 

The following' discussion assumes this texture access: 

float lowvai, nsamples, swid, twid; 
texturef'ar.othermap", "variance", lowvai, 

"samples", nsamples. 

"swidth", swidth, 

'‘twidth", twitith y t 

This call accesses “anothermap" at the current global (s,t) begin- 
ning with channel 0, the "red" channel. (Note that no 
R!_NULL token is required at the end of parameterlisi) 

The remaining parameters concern the sampling of rhe tex- 
ture map. Just as an image pixel represents scene data project- 
ed onto a finite area of the image plane, an access of the tex- 
ture map represents data spread over a finite area of rhe map. 
The extent or this area, and the rate at which it is sampled to 
determine the output value, are parameters of the access func- 
tion. 

The “variance" token-value pair controls how close the sam- 
pled value is to the underlying value in the texture map. The 
meaning of variance in this context is the same as that in the 
discussion of RiPixelVarianceQ in Chapter 9. 

"samples" specifies an effective sampling rate. For values great- 
er than 1 (it makes no sense for it to be less), the texture map 
is accessed nsamples times for each call of texture(). 

The "swidth" and "twidth" token-value pairs control the area of 
the texture map over which an access is sampled. In the exam- 
ple above, swidth will multiply the width of the sampled area 
in s, and twidth will do the same in t. Thus, if both swidth and 
twidth are 2, the area sampled is four times larger. It is appro- 
priate to take samples over a larger area of the texture map 
when the map is being sampled infrequently, as might hap- 
pen when a surface is being shaded at infrequent intervals. 
Normally, though, the area of the texture map sampled is 
matched to the spatial frequency with which it is sampled. 
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Texture access 


color texture' rtsmelchannel], textcoords, parameter iis: 
float texture ' name {channel], textcoords, parameterlis: 
string name; 
float channel; 


A location in the named texture map is read using the built- 
in shading function textureQ. It may return a float or a color; 
if the latter, the access is from three (or more, if the number of 
color samples has been mcreased) successive channels begin- 
ning vdth channel textcoords and parameieriist are discussed 
above. 


Bump map access 


The function for accessing a bump map differs from that for 
texture maps! in both its parameters and its return type. 
bumpO returns a point value that is generally used to perturb 
the surface normal by vector addition. 

The general idea in normal perturbation is that it affects a sur- 
face in the sarpe vvay regardless of the surface's position or ori- 
entation. Therefore, the relative perturbation must depend 
not only on the surface's normal vector, but also on its orien- 
tation about the normal. See Figure 15.2. 


point 

bump(name!cr.anner., norm, dPris, dPdt, textcoords , parameter! ist) 
string name; 
float channel; 
point norm, dPps dPdt; 

The name, channel textcoords and parameteriist arguments to 
bumpO have the same meaning and defaults as they do in tex- 
ture(). The remaining three arguments, all points, are used to 
define a "local" set of coordinate axes for the normal perturba- 
tion. They should be mutually orthogonal. The point re- 
turned from bumpO is normally used to perturb the surface 
normal norm by simply adding the two together. 
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Figure 15.2 Dependence of normal perturbation on surface location and orienta- 
tion. 


Since N, dPdu , and dPdv are mutually orthogonal by defini- 
tion, they make good values of norm, dPds, and dPdt 

bump() may be used even in an implementation that does not 
support bump mapping. There, the returned point is always 
(0, 0, 0), safely indicating no perturbation. 


Environment maps 


color 

environment! namejchanne!], direction, parsmeteriist ; 
string name: 
float channel: 
point direction- 

The function environment) accesses a reflection map. It is in- 
dexed, not by texture coordinates (s, t), but by a point value 
giving a direction vector. The direction will generally be the 
"mirror 7 ' direction given by the incident vector as reflected 
about the surface normal. It should be specified in the coordi- 
nate system in which the environment map was originally 
specified. The color returned is the color of the environment 
in that direction from the viewpoint at which the environ- 
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ment map was rendered. The direction may also be specified 
as a comma-separated set of four points, in which case colors 
from the environment are filtered over the interior of the re- 
gion delimited by the four directions. 


Shadow maps 

A shadow map allows light sources to cast shadows on objects 
without ray tracing. Typically, a shadow map stores the depth 
of the surface nearest a particular light source in a given direc- 
tion. Figure 129 shows the shadow data used in Figure 7.7. 
Surfaces nearer the tight are darker; only they are illuminated. 

Shadow maps, tike reflection maps, represent the world as 
viewed from an object, in this case a light source. They are al- 
so accessed similarly. 


float 

shadow^ name] cnanne position, parameter! ist i 
string name; 
float channel; 
point position; 

The arguments to shadowO are similar to those of environ- 
ment(). position is the location of a point in ’current’' space, 
and name is the external name of a shadow map file created 
from the point of view of the light source accessing the map. 
The shadowspoR ) example in the next chapter will show' ex- 
actly how to use shadowO. 

The return value of shadowO is a single floating-point value. 
It gives the extant to which the surface point is in shadow 7 , 1 
indicating complete shadowing and 0 complete exposure. A 
typical light source shader using a shadow is shown below; it 
uses the shadow value and provides a square-law falloff. 

light shadowlighr: color lightco!or=color (1 ,1,1); float intensity=l ) 

i!iuminate{ P ) 

Cl = llghtcolor * intensity * 0-shadow( ,1 map", Ps))/(L.L); 
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Geometric Functions 

The shading language defines a variety of functions for geo- 
metric calculations. These are summarized in Table 15.2 and 
discussed below. 


Return 

Type 

Declaration 

Meaning j 

i 

float 

x com pi P> 

return .t component of point P 

float 

ycomp'P: 

return y component of point P 

float 

zcomp'P' 

return 2 component of point P 

— 

setxcomp ?, v) 

set x component of point P to float =. 

— 

setycompi p, vj 

set y component of point P to float v 

— 

setzcompiP, vj 

set r component of point P to float . 

float 

length. V' 

return the Euclidean length of point V 

float 

distance PI ,P2) 

return the Euclidean length of (P7-P2' 

float 

area* P 

return the surface element area at P, in 
pixels 

point 

normalize' V- 

rerum V/lengthiV) for point V 

point 

faceforward VJ) 

return V flipped to point opposite \ 

point 

reflect! N 

return reflection of incident ray i about 
normalized vector N i 

point 

refract KN.eta 

return incident ray ! refracted through j 
surface with normal N and index of re- 
fraction float eta 

j 


fresnel; I. N. eta, Kr, 

Kt l R. T 1 ) | 

return reflectance coefficient float Kr, \ 
transmittance coefhaenr float Kt, refect- 
ed ray R, and refracted rav T, given inci- 
dent rav 1, surface normal N and relative j 
index of refraction float eta 

point 

I 

transform; [fromspace. ] tospace, P) 

transform the point P from the coordi- 
nate system named by string fromspace to 
the coordinate space named by tospace 

float 

depth( P ) 

return depth of point P in camera space, 
normalized between 0 at the near clip- 
ping plane and 1 at the far one 

point 

caiculatenormai(P) 

return the normal to a surface at point P 


Table 15.2 Geometric Shading Functions 
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A number of these functions depend on the concept of a sur- 
face element. Under RenderMan, a surface element is a quad- 
rilateral piece of a larger surface, which spans the distance be- 
tween adjacent shading samples. 

For purposes of shading, a surface element is also assumed to 
be geometrically infinitesimal, in the sense of the theory of 
limits in calculus. Specifically, the tangents of a surface ele- 
ment are equated with the change in position across its edges, 
and its normal can be calculated directly from those. In fact, 
the derivative of any varying value at an element is assumed 
to be the same as the values's change across the element. The 
"real" meaning of the global variables du and civ, which give 
the derivatives of the surface parameters at a point, is their 
change across the surface element, du is nothing but the 
change in u across one surface element, and similarly for dv . 

Point components 

Since the shading language does not support structured data 
types, the components of a point are accessed by predefined 
functions. 


float xcomp P j 
float ycompl P ) 
float zcomp{ P } 
point P; 

These functions fetch the x, y and z components from a point 
data object. These components are set with 

setxcompi P, vai ) 
setycompf P, vai ) 
setzcomp; P, vai ) 
point P: 
float vai; 


Vector length 


float length ( V ) 
point V; 
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lengthO returns the Euclidean length of the vector V: 

length(V) = sqrt( xcomp(V)*xcomp(V) ^ 
ycompfV)'ycomp(V) + 
zcomp(V)*zcomp(V)) 

= sqrt( V.V ) 


Distance between points 


float drstance( pi , p2 
point pi , p2; 

distanceO returns the Euclidean distance between points pi 
and p2 : 


distance*, ol . p2 ) = iengthi p1-p2 ; 


Differential surface area 


float area{ P ) 
point P; 

area() returns the raster space area of the surface element at 
point P, its area in pixels. 


Vector normalization 


point normalize! V > 
point V; 

normalizeO returns a vector of length 1 that points in the 
same direction as point vector V. If the length of V is 0, then 

normaiize(V) = point( 0,0,0 ) 

Otherwise, 

normalized) = V / length(V) 
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Normal flipping 

Function faceforwardO ensures that two vectors have a partic- 
ular relative orientation (i.e., they point in opposite direc- 
tions). It is most frequently used in shading to ensure that a 
surface normal points toward a light source or the viewpoint. 


point faceforwardi y, R } 
point V, R; 

If V and R form an acute angle when placed head to tail, then 
faceforwardO returns V. If not, it returns -V. 


Refraction 

Transparent surfaces like glass typically alter the path of light 
passing through them from other materials like air. The 
amount of refraction (the angle of deflection) depends on the 
angle between the entering ray and the surface normal, as 
well as a relative index of refraction, the ratio of the speed of 
light in the two materials involved. 


point refract I \ elk j 
point I N; 
float eta 

refractO takes an entering ray direction /, a surface normal b! 
and a relative index of refraction eta. It returns the direction 
of the refracted rah\ 

If the angle between / and N is too great for a given eta, the ray 
is reflected from the surface and none of it enters the materi- 
al. In that case, refractO returns point (0, 0, 0). 


Proportional reflection and refraction 

In most cases, a ray striking a refractive material is partly re- 
flected and partly refracted. The function fresneK) calculates 
the respective fractions. It may also return the reflected and re- 
fracted direction vectors, so that it subsumes refractO. 
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fresnelf I, N, eta, Kr, Ki[, R, T J ) 
point 1, N; 
float eta, Kr, Kt; 

point R, T; 

As in refractO, I, N and eta are the incident direction vector, 
the surface normal vector, and the relative index of refraction 
between two materials, respectively. When fresnelf) returns, 
Kr is set to the fraction of light reflected and Ki is the fraction 
of light refracted 7 transmitted. In general, Kr and Kt do not 
sum to I. They are fractions of intensity, and refraction chang- 
es intensity" due to focusing and defocusing effects. Both must 
be variables, of course. 

If R and T are supplied, they are set to the direction vector of 
the refracted ray and the transmitted ray, respectively. 


Coordinate system conversion 

When a shader is called, all points are defined in the same 
("current") coordinate system. As mentioned in the last chap- 
ter, a point constant can be expressed in any named coordinate 
system and implicitly converted to the "current" system. To 
convert point variables, or to convert constants to systems oth- 
er than "current", requires an explicit function: 


point transform! [fronsoace, S tospace, P v 
string fromspace. tospace; 

point. P; 

transTorm() converts the point P from the coordinate system 
named by fromspace to the coordinate system named by 
tospace . If fromspace is omitted, "current 11 is used. 


Relative depth 


float depth( P ) 
point P; 
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depthQ takes a point coordinate in three-dimensional space 
and returns its distance in z from the camera. The depth re- 
turned is normalized so that points on the near clipping 
plane are at depth 0, and on the far clipping plane, 1. 


Normal calculation 

When a displacement or deformation shader transforms the 
global surface point P, it also has the responsibility for reset- 
ting the surface normal N. This can usually be accomplished 
easily by calling: 


point calculatenormal F j 

point P; 


calculatenormal! 

) determines the surface normal of a surface 

element based c 

n the change in P across the element, as in Fig- 

ure 15.3: 


N - d°GL 

V-dPdv 


Color functions 

Four functions are provided to perform basic operations on 
colors. 

Accessing color components 

Treating color as an abstract data type works out in almost all 
cases, but when it is really necessary to access the individual 
components of a color, compQ and setcompQ are available. 


float comp( c, index ' 
color c; 
float index; 

setcomp( c, index, value ) 

color c; 

float index, value; 
float ncomps ; 
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compQ returns the value of the index th component of color c. 
setcompO sets it. For purposes of driving loops over the com- 
ponents of a color, the actual number of components being 
used is stored in the global variable ncomps. A shader should 
never assume that there are only three components per color. 


Color mixing 


color mix( colorO, color*! , a ) 
color coiorO, color! ; 

float a; 

Two colors can be intermixed by calling the function mix() 
with a value of a between 0 and 1. The color returned is 

(l-a)*co/orO+ a* color! 
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Printing 

Messages can 


printfQ. 


be printed from a shader to a user by using 


prints format. vail > 

string format; 

printfO is sim: 
er, the onlv 


are "%f for a 


Jar to the C function of the same name. Howev- 
iormat specifiers supported in the format string 


string. 


for a 

ments must 
implements tid: 
the user's con 


float, "%p" for a point, "%c" for a color and n %s" 
\aturally, the types of the corresponding argu- 
match the specified tvpe. Printing occurs in an 
n [-dependent manner, but usually appears on 

sole. 


Further Reading 

The improvements on Phong shading were developed by Jim 
Blinn [BLL\ : .\ T p]. The use of the noiseO function can best be 
understood by reading Ken Periin's paper "An Image Synthe- 
sizer" [PERL1NS5]. 
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CHAPTER 16 


A Gallery of Shaders 


r After three chapters on the theory of writing shaders, 
* this chapter concerns the practice. There are almost 
three dozen examples showing how it's done and il- 
lustrating the power of this approach ro shading. The first five 
sections of this chapter cover a variety of basic techniques and 
discuss a case study: given a detailed model, how to present it 
in the best possible light with different shaders for different ef- 
fects. Where appropriate, there is a color plate illustrating the 
effect of a shader. The sixth section discusses some of the oth- 
er color plates, which have no shader, and we close with a 
look to the future. 

The shaders presented here vary in a number of ways. Some 
are included primarily to illustrate a point or two, some show 
interesting ways of doing things, some show' how 7 to do some 
interesting new* things, some are robust shaders intended for 
general use, and some are just for fun. Each one should help 
the user make the most of this new method of shading. 


Standard Shaders 

We begin with the shaders defined as a standard parr of the 
RenderMan Interface. They were discussed in Chapter 11 
from the user's point of view. The purpose here is twofold: to 
begin the discussion with some basic examples, and to give 
them a more formal definition. Even for implementations 
that do not support the shading language, the functionality of 
these shaders must be provided. 
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Constant surface 

A constant surface alwavs has the surface color Cs as declared 
with RiCoIor(:' and the surface opacity Os declared with RiO- 
pacityO. It copies the surface reflectance Cs directly to the out- 
put color G7, as though the surface were illuminated with a 
white ambient light of intensity 7 1. This change of meaning is 
implicit in the assignment, but the distinction between reflec- 
tance and color is worth keeping in mind. 


/' 

' constant •: sumacs shade - giving a constant color 

surface 

constant 


Oi = Ov 
Ci =■ or d: 

Listing 16.1 CpisftfiiS'flfor surface shader 


In the constant shader, the output color Cl is scaled by the 
opacity of the surface Ot. There are a number of justifications 
for this requirement [PORTER84], but conceptually the sim- 
plest explanation is that it allows colors from behind the sur- 
face to show through (add to Cf) without overflowing the 
bounds of a color. 

Matte surface 

A matte surface exhibits only diffuse reflection, because it scat- 
ters light uniform] v with no preferred airection(s). That 
makes the apparent brightness of such a surface independent 
of the direction from which it is viewed. 

The first line of matte () calls the faceforwardO function, 
which returns its first argument, a vector, unchanged except 
that it may be reversed in direction to "face forward" (form an 
acute angle) with respect to the second argument. In this case, 
the surface normal is made to face forward with respect to the 
"incident direction" I. If a two-sided surface is viewed from its 
back side, as defined and discussed in Chapter 7, the surface 
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r 

* matteO: simple diffusely-reflecting surface 

V 

surface 

matte; 

float Ka = 1 , 

Kd = 1 ) 

i 

point Nf = faceforwardfnorrnalize(N),J); 

Oi = Os; 

Ci = Os " Cs * Ka'ambientO + Kd"diffuse(Nf) ) ; 


Listing 16.2 Matte su^ace shader 


normal faces away from the incident direction and must be re- 
versed if shading calculations involving it are to be correct. 

The incident direction I (the global variable f) may be thought 
of as the direction of view. In many cases the viewing direc- 
tion is from the camera, but not always, which is why J and 
camera location E are distinct. In a ray tracer, for example, the 
"viewing direction" might be from a highly specular surface 
that is "viewing" another surface for purposes of reflection. 
No shader should assume that [ and E are related, and the worst ex- 
ample of that error is to use (P-E) instead of /. 

The last line of mstteO sets reflected color O to the product of 
opacity Os, surface color Cs, and a weighted sum of the func- 
tions ambientO and diffuseO. The former function calculates 
the total color of all ambient light sources, and the latter calcu- 
lates the light striking the surface at point P, with a falloff due 
to the orientation Nf, passed as its argument. Note that while 
a vector other than N may be passed to diffuseO, it always as- 
sumes that P is the point being illuminated. The values re- 
turned by ambientO and diffuseO are light values; these are 
scaled by the ambient and diffuse coefficient instance vari- 
ables Ka and Kd, then multiplied by the surface reflectance Cs 
and opacity Os to get the light emerging from the surface due 
to reflection. 

diffuseO demonstrates the need for Nf to point correctly. Since 
diffuseO believes whatever vector is passed to it, if the normal 
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points in the wrong direction it will calculate the diffuse re- 
flection on the wrong side of the surface! 

Metal surface 

The next step up in realism is to include specular reflections 
from the surface. In fact, the only difference between matte 0 
and the metalQ surface shader is that the latter substitutes a 
specular reflection for the former's diffuse component. 


/' 

' metalt,: give a surface a metallic appearance 
V 

surface 
meta! ( 

float Ka = 1 , 

Ks = 1 

rojgnne^ - .25 

1 I 

point Nlf = facetorward;normaIize’V i) ; 


Oi = Os; 

Ci = Os " Q * ( Ka*ambient(, -r Ks*specuiar(N‘? -], roughness) ); 


Listing 16.3 Sunqcc shader giving a metallic appearance 


As outlined in the previous chapter, the specular() function 
implements a surface reflection that is not diffuse (evenly scat- 
tered in all directions), but is rather concentrated around the 
mirror direction. The instance variable roughness of metalQ is 
passed to specular () to control the concentration of the specu- 
lar highlight, a high roughness value giving a more diffuse re- 
flection. 

Plastic surface 

The plastic surface shader is a combination of matte 0 and met- 
alQ, with the addition of a separate color for the specular high- 
light. This shader serves a model of plastic as a solid medium 
with microscopic colored particles suspended within it. The 
specular highlight is assumed to be reflected directly off the 
surface, and the surface color is assumed to be due to light en- 
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tering the medium, reflecting off the suspended particles, and 
re-emerging. This model explains why the color of the specu- 
lar reflection is different from the surface; it also explains why 
so many early high-quality computer graphic images looked 
like plastic: their specular reflections were white, unlike the 
diffuse reflections [COOKS1]. 


f* 

/ 

' plasticO: give t he appearance of a plastic surface 

V 

surface 

plastic 


float 

K$ 

= .5, 


Kd 

= *5, 


Ka 

= 1, 


roughness 

= .1 ; 

color 

specularcolor 

= 1 


point Nr = faceforward(normalizeiN), 1 ); 
point V = normalize* -I] ; 

Oi = Os; 

Q = Ql x * Ka'ambientQ - Kb“diffuse ; NT)i - 
specuiarcolor * Ks * specular Nf,v, roughness 


Listing 16.4 Surface shader tor a plastic appearance 


Ambient light 

An ambient light source supplies light of the same color and 
intensity to all points on all surfaces. As a result, it is about as 
simple as the constant i) surface shader. All it does is multiply 
its instance variables, lightcolor times intensity. The result is 
placed in global variable G, which is the output of all light 
sources. 

It is not strictly necessary that lightcolor and intensity be sepa- 
rate instance variables. The color could just a easily be scaled 
by the intensity by the application before instancing the shad- 
er. RenderMan keeps the two separate in honor of the notion 
that the components of a color are in the range [0,1]. 
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* ambient! ight{): hon-directional ambient light shader 

light 

ambientlightt 

float intensity = 1 ; 
color ligbtcilor* 1 ) 

i 

Cl = imensitj " lightcolor; 

} , 

Listing 16.5 Ambien: light source shader 


Distant light 

Unlike an ambient source, a distant source casts its light in 
only the direction defined by its instance variables to and 
from. The vector defined by the difference of points ( to-from ) 
is used in a solar statement to restrict the emission to that di- 
rection. Otherwise, the output light is the same as in ambi- 
ent(). 


' distant! ignt . ide the behavior of a ouasi-solar Ugh: source 

V 

light 

distantiighti 

float intensify = 1 ; 
color lignicolor = t ; 
point from = point "camera" (0,0,0), 
point "camera" (0,0,1 ) j 

I 


TO 


solar ( to * from, 0.0 } 

Cl = intensity ' lightcolor; 


Listing 16.6 light source shader 


to and from are defined in shader space. That is, they are in 

the current coordinate system at the time the shader was in- 

✓ 

stanced. This is in contrast to the case where they were de- 
fined in an explicit space. For example, the shader might be de- 
clared as 
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light 

distant!ight{ 

float intensity = 1 ; 

color lightcolor = 1 ; 

point from = point "camera" (0,0,0) ; 
to = point "camera" (0,0,1 1 ) 

This light would invariably point along the positive z axis of 
camera space, regardless of the configuration of the scene or 
camera. The same would be true of any other named space in 
the declaration. For example, one could arrange a '’traveling" 
camera in animation simply by naming the appropriate space. 
The lesson here is that a distant light source instanced with ex- 
plicit position and direction is treated like any other object. 


Point light 

A point light source is the converse of a distant light. It radi- 
ates light in all directions, but from a single location. It has a 
from instance variable, but no to. 


/* 

’ pointlightO: proxice a light with position but no orientation 

V 

light 

point! ignt( 

float intensitv = 1 ; 
color lightcolor = 1 ; 

point from = point "camera" (0,0,0) ) '* lisht position */ 

{ 

illuminate' from 

Ci = intensity * lightcolor / L.L; 


Listing 16.7 Point light shader 


from is used in an illuminate statement. Inside, the output cal- 
culation is as it was in distantlightQ, but the color is divided by 
L.L Within illuminate (the only place it is defined), l is a vec- 
tor from the position of the light source to the surface point 
being illuminated. Its length is therefore the distance from 
the point source to the surface point, so the dot product L.L 
gives the square of the distance, which is exactly the quantity 
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required to implement a square-law falloff of light intensity 
with distance from the source. 

Spotlight 

The spotlighH ) shader is shown in Listing 16.8. It also uses the 
illuminate construct, but it supplies not just the spotlight posi- 
tion, but also a cone of illumination. The latter is specified as 
a direction, A. and a width, specified in radians by the conean - 
gle instance variable. 


/* 

' spotlight : : 

as' a fuz 2 \ cone of light 

V 

light 

spotlight? 

fioat mi 

ensit\ 

= 1; 

color iighicoio* 

= 1; 

point froir 

= point 'camera" (0,0,0; '* light position V 

to 

fioat co 

lea.ngie 

= point "camera" (0.0,1 ; ’’ light direction tL/ 

- radiarrs;30 y , 

:o 

neoeiraa: 

igie = radians(5/, 

:>e 

i 

jmdisric 

ijtion = 2 > 

1 

uniform | 

point 

A = (to - from! length (to - from • 

uniform 1 

Fioat 

cosoutside= cos(coneanglej, 

fioat aai 

1 

jangle ; 

cosinside = cosiconeangle-conedeltaangiej; 


illuminate from, A. coneangie ) ( 
cosangie - L.A / lengthtLj; 
artpn = powtcosangle, beamoistribution (L.L); 
attsen *= smoothstepi cosoutside, cosinside, cosangie ); 
C_ = atten ' intensity * lightcoior; 

1 


Listing 16.S Spotlight shader 


SpotlightQ begins by calculating the vector A, its direction, as 
the difference of points to and from . The vector is divided by 
its own lengthO to ensure that it is 1 unit in length. A is a uni- 
form variable, the first example of one such we have seen; 
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since its value depends only on from and to, which are also 
uniform, it can be calculated once when the shader is in- 
stanced and used every time the shader is called. 

Within the illuminate block, the spotlight uses the illumina- 
tion vector L to calculate the square-law failoff with distance 
from the light. This time, though, L is also used to determine 
the angle between the direction to the surface point and the 
cone center. Since the dot product of two vectors A and B with 
angle theta between them is A.B = I A . I B I cosiiheia), the cosine 
cosangle of the angle between L and the cone direction vector 
A is given by A.L/ Ml I L I . A is set in the beginning to length 1, 
so the division is only by the length of L 

The failoff from the cone center is based on this cosine: it is 
raised to the power beamdistribution, and the square-law fai- 
loff is brought in by dividing by L.L. Finally, the smooth barn- 
door failoff is provided by calling smoothstepO. If cosangle is 
less than cos (coneangle-conedeltaangle) — the surface point 
lies well inside the cone — the failoff is 1 and the attenuation 
is unaffected. If greater than cos (coneangle) — the point is out- 
side the cone — the attenuation and the illumination go to 0. 
In between there is a smooth failoff. Note that smoothstepO 
still works correctly even if its second argument (nominally 
max ) is less than its first (min). 

Depth-cue volume 

A depth-cue volume shader, normally used by RiAtmo- 
sphereO, linearly adds a specific color background to C[ accord- 
ing to the distance between the surface and the eye. The color 
added is 0 if the surface is less than mindistance away. Tne 
background color eliminates the surface color entirely for 
points farther than maxdistance. In between, the two colors 
are mixed. 

The mix() function implements a linear interpolation be- 
tween its first and second parameters based on its third param- 
eter, which should be between 0 and 1. This mix ratio is calcu- 
lated in the call to clampO, which is here used to determine 
the relative distance of surface point P (which produced Cf) be- 
tween mindistance and maxdistance. The depthO function 
gives the distance of P from the camera. It is equivalent to 
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* depth cue(): darker, objects according to their depth. Mincistance and 

* maxdistance cover the range between dipping planes. 

*/ 

volume 

depthcuei 

float mindistance = 0, 
max distance = 1; 
color background = 0 ) 

\ 

float o = clamp tdepthfPj - mindistance) / (maxdistance - mindistance), 

0 . 1 ); 

Ci = mix Ci. bacKEround, d ); 

• [ 

Listing 16.9 Dr::n-tue volume shader 


length (P-£). In this case we may assume that the view is from 
the camera under the assumption that this shader will be 
used for atmosphere. length (/) could be used otherwise. 


Fog volume 


A fog shader is a 
spheric absorption 
face color in the i 
shader, but only 
tion. 

: somewhat more realistic function for atmo- 
n. It assumes that the attenuation of the sur- 
og is never complete, as it is in the depth-cue 
asymptotically approaches complete attenua- 

/*- 

' fog(): introouce oep 

•/ 

'tn-bBf.ee (og 

volume 

TOg ( 

float distance 

= 1; 

color bsckgrour 

/ 

ic = 0 ) 

\ 

float d = 1 - exp 

{ -length(])/distance ); 

Ci = mix( Ci, background, d ); 

} 

Listing 16.10 Vog volume shader 
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Instead of linearly interpolating the distance to the surface be- 
tween two arbitrary distances, fogO takes 

l-e~ r 

where r is a relative distance, taken as the ratio between the ac- 
tual distance to the surface and the distance passed in instance 
variable distance. The latter specifies the distance at which the 
relative amount of fog is (1-1 /e). 

This concludes the discussion of the built-in shaders. Their 
functionality is guaranteed to be available by the definition of 
RenderMan. In the remainder of the chapter we present origi- 
nal shaders. The capability to write them is only available in 
implementations supporting the RenderMan Shading Lan- 
guage. 


Procedural Texturing 

Since the RenderMan Shading Language is a full-featured pro- 
gramming language, one of the simplest techniques it allows 
is procedural texturing, by which textures are generated on 
the fly based on object geometry. A procedural texture can be a 
function of surface parameters. More important, though, it 
can also be defined in terms of points in three-dimensional 
space. For example, if the color of a marble material can be de- 
fined and computed for any point in three-dimensional space, 
the procedure that computes it can be used as a procedural tex- 
ture for surfaces in three-dimensional space [PEACHEY85]. 
This offers the possibility of an interplay between the surface 
of the object and the texture that makes the object appear to be 
carved out of a solid material. 

Since a three-dimensional space is potentially huge, a proce- 
dural texture can also represent information that, if stored ex- 
plicitly as a texture, would require prohibitively large 
amounts of storage — it's one thing to store two dimensions of 
texture, quite another to store three or four. A procedural tex- 
ture can also . be given parameters to vary its appearance in 
subtle ways that would be difficult to duplicate with a fixed 
texture. 
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Object space functions 

We begin with some simple shaders for setting surface color 
and opacity as functions of surface and obiect-space coordi- 
nates. 

show_st surface 

The surface shader show_stQ, shown in Listing 16.11, shows 
just how simple a shader can be. For each point on a surface, 
it sets red and green in the output color to the texture coordi- 
nates at that point Red and green will be se: regardless of the 
color space defined by RiColorSamplesO, since the color is cast 
with “rgb". This is actually redundant, since 'rgb‘ would have 
been assumed in the absence of an explicit cast.) The shader al- 
so sets the surface opacity to 1 (completely opaque), ignoring 
that set by RiOpacitv(). Like color Cs, Os is only an advisor}’ 
value and may be ignored by any shader. 

Since color channel values normally lie in the range [0,1], and 
so do texture coordinates, this function is reasonable: under 
the default texture coordinate space, the upper left (s=0,t=0) 
comer of a surface in s,t space will be black, the upper right 
red, the lower right yellow and the lower left green. If texture 
space is changed by RiTextureCoordinatesQ or vertex binding 
so that texture coordinates are not the defaults, the results 
will be different. The parametric coordinates u and v might 
seem to be a better choice to use, but thev are alwavs fixed 
over a surface; ip the user wants to redistribute the colors over 
a set of adjoining surfaces, only texture coordinates will do. 


' show st{): color surface point according to its s,t coordinates. 
V 

surface 

show_st() 

i 

Ci = color 'Tgbl (s, t, 0); 

Oi = 1 ; 

I 

Listing 16.11 Shader mapping texture-space coordinates to colors 
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Plate 1 shows the result of applying show^stQ to a light bulb. It 
reveals that the globe of the light bulb consists of a hemi- 
sphere and four patches. This shader is useful during the de- 
bugging process for displaying the boundaries of surfaces. 

checkerboard surface 

The shader checksQ in Listing 16.12 shows how to use texture 
space to provide a patterned surface, in this case a checker- 
board. 


' checker*): surface shader for applying a checKerooarc partem. 
V 

surface 

checker! 

float K d = .5. 

Ka =.l, 

frequency = 10; 
color blackcoior = color (0,0,0) ) 

I 

float smod = nod!S~:requency 1 h 
tmoc = .nodtt“rrequency,*i); 

iftsmod < 0.5 
if(tmod < 0.5 » 

Ci = Cs: 

else 

Ci = biackcolor; 

! else { 

if(tmod < 0.5 > 

Ci = blackcoior; 

else 

Ci = Cs* 


Oi « Os; 

Ci = Oi*Ci*( 

Ka*ambient() - 

Kd“diffuse'faceforward(normaIize(N)J)) ); 

1 

Listing 16.12 Surface shader providing checkerboard pattern 


The frequency instance variable of checksi) states how many 
times the checkerboard pattern is to repeat within a single 
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Figure 16.1 Checkered light bulb 


unit interval of s and t. Therefore, when the texture coordi- 
nates of a point are multiplied by frequenc), the fractional part 
of the result gives the "phase" of the cycle of that point. If 
smod and tmod are both less than or both greater than 0.5 (s 
and t are both in the first half or both in the last half of a cy- 
cle), the surface color Cs is used to shade the point, otherwise 
the instance variable blackcolor determines the color. 

Figure 16.1 shows the result of applying checksQ to a light 
bulb. The revealing thing about this image is that the checks 
are not all square; on the hemisphere at the top of the bulb 
they are especially elongated, although they bunch together 
more at the top. This is because 1 unit of s (10 check cycles) 
covers the entire circumference of the sphere, while 1 unit of 
t providing the same number of cycles only goes from the 
equator to the pole. 

Figure 16.1 is a graphic illustration of the fact that texture 
space is not uniform in world space. Actually, it is difficult to 
imagine how it could be otherwise over a curved surface like 
this one. For example, the length of a unit of s space goes to 0 
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at the poles of a sphere. In many cases there are ways of linear- 
izing parameter space again, and it can help to redistribute tex- 
ture space with RiTextureCoordinatesO, but it is a recurrent 
and important problem. Often the solution is to use world 
space directly, as in the next shader. 

show_xyz surface 

The third simple example of a mapping from surface position 
to output color is shown in Listing 16.13. The show_xyz { ) sur- 
face shader maps points within a bounding box, given by its 
instance variables, into red, green and blue values in the 
range [0,1]. 


/- 

' show_xyz(): Color a surface point according to its xvz coordinates 
* within a bounding box. 

V 

surface 

show_xyz( 

float xmin = -1 . 
vmin = -1 , 
zmin = -1 
xmax = 1 . 
vmax = i, 
zmax = 1 ) 

! 

uniform point scaie zero; 
point objP, cubeP; 

/* Check for zero scaie components. V 
if(xmax==xmin li ymax==ymin tl zmax==zmin) { 

printf( "bad bounding box %f %f %f % t 0/ of %f in $how_xvzO" r 
xmin, xmax, ymin, vmax, zmin, zmax ); 

1 else ( 

scale = point {1/(xmax-xmin), 1/(ymax-ymin), lAzmax-zminjj; 
zero = point (xmin, ymin, zmin); 

objP = transformC'shader 1 ', P); 
cubeP = I'objP - zero) “ scale; 

Ci = color (xcomp(cubeP), ycomp(cubeP), zcomp(cubeP)); 

! 

} 

Listing 16.13 Shader mapping shader-space coordinates to colors 
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I 


show_xyzQ wdrks in '‘shader" space, the coordinate space in 
which the shacer is instanced. The space in which a shader op- 
erates is impor:ant to the coherence of the shading. Using a co- 
ordinate space shared by all the surfaces of an object ensures 
that adjacent points on two different surfaces in the image 
will be coiorec similarly. If, by contrast, the object space of 
each object were used instead, there would be no such guaran- 
tee possible, and if world space were used, objects' appearances 
would change as they moved in animation. Using coordi- 
nates in a physical space may also lend a uniformity of appear- 
ance difficult to achieve using parametric coordinates. 


screen surface 


A slightly more complex use of texture coordinates is shown 
in the screenO shader of Listing 16.14. This shader is a modifi- 
cation of the plastic surface shader that provides ambient, dif- 
fuse and specular reflections. The difference is in opacity. A 
regular grid is laid over the surface in s,t space, and points that 
lie in the middle of grid squares (that are more than a certain 
distance from th= grid lines) are shaded with opacity of 0, mak- 
ing them transparent. That is all the shader has to worn > about. 
The renderer takes care of displaying surfaces behind the 
transparent porti ons of the surface. 


The frequency ir 
there are per uni 
lines per surface 
parameter contrc-L 
The default .25 " 
texture space horijz- 


.stance variable controls how many grid lines 
: in s and t; the default 20 produces 20 grid 
under the default texture space. The density 
,s the portion of the surface that is opaque, 
ijneans that the "wires" will cover 25% of the 
ontaliv and 25% verticallv. 


In Plate 3, the tdapot at the bottom shows the effect of using 
the screenQ shader. 


Anti-aliasing thresholds 

The conditional ir screenQ is theoretically sound, but it is an 
either-or test, wh.ch can sometimes lead to aliasing problems 
arising from the hard edge it produces. A useful technique for 
eliminating this hazard is to put a "fuzzy" edge onto the edges 
of the screen usinlg the smoothstepO function. If fuzz is an in- 
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stance variable giving the width in texture space of a transi- 
tion between points which are on the screen and those off the 
screen, then it can be used to replace the conditional state- 
ment above with 

Oi = 1 - smoothstep( density-fuzz/2, 
density-!- fuzz/2, 
modts"frequency,1 ;} 

‘smooth$tep( density-fuzz/2, 
density +fuzz/2, 
mod(t*frequency, 1)); 

The smoothstepO function defines a range with its first two pa- 
rameters. It returns 0 if its third argument is outside the range 
from below (i.e., if the surface point is completely inside the 
screen), 1 if outside above (completely outside the screen), and 
ramps smoothly in between. The effect here is to blur the edg- 
es of the screen by varying the surface's transparency. 
smoothstepO is a very useful tool for reducing aliasing. 
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A 

*screen{): surface shader for giving "wireframe" appearance. The method is 
to render the surface opaque within a small distance of a grid in s,< 

* space. The grid is derived from a modulus function. 

V 

surface 

screen( 

float Ks = .5, 

Kd = .5, 

Ka =.1, 

roughness = .1 , 
densitv = .25, 
frequencv = 20; 

color specuiarcolor = color 1,1,1)} 

i 

varying point Nf = faceforwardi normalize! \) 1 ; 


if mod(s*freGuencv,1 < densitv I mod{t“trequencv.1 . < densit\ 

Oi = 1 .0; 

else 

Oi = 0.0; 


G = Oi * ( Cs * f Ka“ambient( -r Kd M diffuse, \f) - 

specularcolor*K$*$pecuiariNf,normalize'-l),rougnness 


Listing 16.14 Shader outlining an object with metallic wire mesh 


Noise functions 

A very useful class of procedural textures uses the shading 
language's npiseO function, operating on points in a common 
coordinate space. The uses of noise in procedural texturing 
are discussec in Ken Perlin's paper ".An Image Svnthesizer" 
[PERLINS5]. 


wood surface 


The woodi > s 
the noiseO fun 
It operates in 
carved out of 
mation. 


lader shown in Listing 16.15 shows how to use 
ction to give a surface a wood -grain appearance, 
object space, as if each surface were separately 
wood and assembled by the modelling transfor- 


The basic idea is that a tree consists of concentric rings that 
can be modeled by cylinders warped with noise. In this case, 
the cylinders are centered on the * axis. The warp depends on 
both the angle about the axis (spoke) of a point and the point's 
distance from the axis (r). After perturbation, r is mapped into 
the range 10,1], then passed through the smoothstepO function 
twice. Multiplying the pairs of smoothstepOs shown here has 
the effect of creatine, a function that rises smoothly to one be- 
tween 0 and 0.3, then falls sharply back to zero between 0.83 
and 0.86. 

r is then used to select between two colors of wood, and also. 


interesting]}', to 


control the shininess of the surface. This fea- 


ture simulates -he characteristic of real wood that the dark 
parts absorb less finish and so appear shinier. 

The small elephant in Plate 4 shows the woodi) shader in ac- 
tion. Close inspection confirms the aforementioned (subtle) 
variation in shirliness. The difference between using a proce- 
dural three-dimensional wood texture and a two-dimension- 
al texture map ia the difference between canting an object out 
of wood and wrapping a picture of wood around the object. 


dented 

The dentedi ) shader in Listing 16.16 uses fractal noise to per- 
turb a surface. The loop sums the output of noiseO over six oc- 
taves. The sequerce of values passed to noiseO are doubled 
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/* 

0 wood(): calculate a solid wood texture using noiseO 

V 

surface 

wood( 


float ringscale 
color lightwood 
darkwood 
float Ka 
Kd 
Ks 

roughness 


= 10 ; 

= color (0.3, 0.1 2, 0.03), 

= color (0.05, 0.01, 0.005); 

= 0 . 2 , 

= 0.4, 

= 0 . 6 , 

= 0.1 ) 


point NN, V: 
point PP; 
float y, z, r; 

/ 

' Compute the forward-facing normal NN and the vector 
0 toward the ray origin V , both normalized. 

0 These vectors are used by "soecular" and " diffuse ". * 

NN = facetorward(normalize(N),l); 

V = -normalized); 


/* put point in shader space and perturb it to add irregularity * 
PP * transformf'shader", P); 
pp += noisePP); 


/* compute radial distance r from PP to axis of "free" ' 

y = ycomp(PP); 
z = zcomp(PP); 
r = sqrt(y*y - z’z); 

/ m map radial distance r into ring position [C, 1 1 0 
r *= ringscale; 
r += absfnoiseir)); 

r -= floor(r); /* == mod(r,l) V 

/* use ring position r to select wood color 0j 
r = smoothsteptO, 0.8, r) - smoothstep(0.83, 1 .0, r)): 

Ci = mixdightwood, darkwood, r); 

/* shade using r to vary sh ini ness */ 

Oi = Os; 

Ci = Oi ‘ Ci ’ (Ka * ambientQ Kd * diffuse(NN)) 

+ (0.3“r * 0.7) * Ks * specular(NN, V, roughness); 


Listing 16.15 Surface shader providing wood-grain texture 
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(using size ) each time through the loop to obtain successively 
higher-frequency noise. The return value is also scaled by 
size , effectively creating a 1/f noise function. The resulting 
displacement is exaggerated by taking it tc the third power. 
The single instance variable Km controls the absolute amount 
of indentation. Note that dentedO only resets the surface nor- 
mal /V, not position P, and that calcuiatenormalO works fine 
nonetheless. 


A 

'dented'*: C r eaie a worn surface. 

V 

displacement 

dented 

float Km =1.0' 

I 

float sue =1.0 

magnitude = 0.0. 


point PC* 

P2 = transform f"shade r ", P 
for ii = 0' i | 6.0; i -= 1 .0 i 

" Calculate a simple fractal 1/f noise functior ' 
masnjtuDe -= abs .5 - noise(P2 * size)l 'size' 

size 4 2.0; 

i 

P2 = £ - normal ize(N) * (magnitude * magnitude * magnitude * Km* 
ts caiculatenormal(P2 

) 

Listing 16.16 Displacement shader io dent c surface 


The surface of the middle elephant in Plate 4 was bumped 
with dentedO, then shaded using the standard metalQ shader. 

eroded 

The shader erodedO, shown in Listing 16.17, does a similar 
job, but in the context of a surface shader. It also uses a noise 
function to calculate a disturbance on the surface, but it also 
uses smoothstepO to threshold the opacity of the surface ac- 
cording to the perturbation: if the perturbation magnitude is 
less than .0001, the surface is taken to be transparent (opacity = 
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0); if greater than .003, it is opaque (opacity = 1). In between, 
the opacity will be smoothly graded between 0 and 1. 

Once the opacity has been calculated, the surface is shaded us- 
ing the plastic surface algorithm and instance variables Ka, Kd 
and Ks. 


/• 

m erodedO: Simulate a metallic surface eaten awav with acid 


V 

surface 

eroded( 

float Ks = .4, 

Ka *.l. 

Km = 0.3, 

roughness = .25 

{ 

float size = 4.0, 

magnitude = 0.0, 


i; 

point Nf, 

W = transformrobjectT P); 
point x=n ,0 0); 


for fi = 0; i < 6.0: i -= 1 .0) ( 

/* Caicuiate a simple fractal 1/f noise function * 
magnitude -= 4.0 * abs(.5 - noise 1 . Wslze size; 
size ’= 2.0; 

I 


A sharpen peaks K/ 

magnitude = magnitude * magnitude * magnitude * Km; 

N = calculatenormalt P-magnitude'normalize ( N ; 

Nf = faceforward! normaiize(N), 1 ) ; 
point V = normalize!-]); 

Oi = smoothstepfQ.OOOi , 0.003, magnituaej; 

Ci = Qi * Cs * iKa m ambient() + Ks*specuIartNr,V,roughness) ) ; 


Listing 16.17 Surface shader eroding the surface of an object 


In Plate 3, the teapot at right was rendered using erodedO . As 
with screenOr other surfaces show through where the opacity 
is not 1, without any intervention by the shader. 



Procedural Texturing 


353 


granite surfa 


ce 


Listing 16.18 shows the shader granite (), which uses another 
six octaves oi 1/f noise to calculate a diffuse granite-like sur- 
face. 


* granite-' : Provide c diffuse granite-like surface texture. 

V 

surface 

granite 

float K6 « .6 
Ka 


i 


float sum st 
float freq 

tor * 0; f 
Sum : 
freq * 


Listing 16.18 Su* 


0; 

h 1 .0; 

6 : i = -i - 1 { 

sum - absi.5 - noise: 4 ' freq * ]))/freq * 


C = Cf * stm * t Ka - Kd ’ difruseffaceforward normalize(N;, | )i 1 ; 


ace shader for granite-like surface 


blue_marble surface 

The final noise-based shader lends a particularly delicate mar- 
ble-like appearance to a surface. blue_marblei) is shown in 
Listing 16.19. 

blue_marble { ) is based on the observation [PERLIN85] that the 
effect of Turbulence can be modeled by several octaves of noise 
whose magnitude decreases with frequency 7 ("1/f noise”). The 
shader calculates such a turbulence function, then uses the re- 
sulting value, between .75 and 1, in a spline between several 
shades of blue representing different colors of marble. 

The blue teapot in Plate 3 and the rearmost elephant in Plate 4 
were both shaded with blue_marble{). 
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/* 

* blue marble(): a marble stone texture in shades of blue 

7 

surface 

blue_marble( 

float Ks = A, 

Kd = .6, 

Ka =.1, 
roughness = .1, 
txtscale = 1 ; 
color specularcolor = 1 ) 

I 

point PP; f scaled point in shader space V 

float csp; /* color spline parameter 7 

point Nr; /' forward- facing normal 7 

float pixeisize, twice, scale, weight, turbulence; 

f* Obtain a forward-facing normal for lighting calculations . */ 

Nf = faceforward(normalizefN), \j; 

/* 

* Compute " turbulence " a la [ PERUN851 . Turbulence is a sum of 

* "noise" components with a fractal " 1/f powe r spectrum. It gives me 
9 visual imoression of turbulent fluid flow (for example, as in the 

* formation of bluejnarbie from moiten color splines!,. Use the 
9 surface element area in texture space to control the number of 
9 noise components so that the frequency content is appropriate 
9 to the scale. This orevents aliasing of the texture. 

7 

PP = transiorm^shadeP 1 , P) * txtscale; 
pixelsize = sqrt(area(PP)); 
twice = 2 “ pixelsize; 
turbulence = 0; 

for (scale = 1; scale > twice; scale /= 2) 

turbulence -»-= scale * noise(PP/sca!e); 

/* Gradual fade out of highest- frequency component near limit 7 
if (scale > pixelsize) I 

weight = (scale / pixelsize) - 1 ; 

weight = clamp(weight r 0, 1); 

turbulence weight * scale * noise(PP/scaie); 


/* 

* Magnify the upper part of the turbulence range 0.75:1 
9 to fill the range 0:1 and use it as the parameter of 

* a color spline through various shades of blue. 

7 

csp = clamp(4 * turbulence - 3, 0, 1); 
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Ci = color spline(csp, 

color (0.25, 0.25, 0.35), /* pale blue 7 

color (0.25, 0.25, 0.35), /* pale blue V 

color (0.20, 0.20, 0.30), /* medium blue 7 

color (0.20, 0.20, 0.30), A medium blue 7 

color (0.20, 0.20, 0.30), A medium, blue 7 

cplor (0.25, 0.25, 0.35), /* pale blue 7 

color (0.25, 0.25, 0.35), /* pale blue 7 

color (0.1 5, 0.1 5, 0.26), /* medium dark blue 7 

color (0.1 5, 0.1 5, 0.26), A medium dark blue 7 

color (0.1 0, 0.1 0, 0.20), /* dark blue 7 

color (0.1 0, 0.1 0, 0.20), /* dark blue 7 

cplor ^0.25 0.25,0.35), /* pale blue 7 

cplor (0.10, 0.10, 0.20) /* dark blue 7 


** Multiply this color bv the difiuselv reflected iight. *, 

Ci ’= ka ’ambient - Kd*cfiffuse(Nif); 

** ~>c:-us: for opacit\ . * 

o; = Os 

C = C 1 Oi- 

" Add ir specular highlights. 7 

C -= sqetjiarcolor * Ks * specular(N:\ normalize -!, roughness); 

> 

Listing 16.19 Blue marble surface shader 

r == — ■ = 


Other functions 

The shaders windowhighlightQ and windowiightQ, shown in 
Listings 16.20 and 16.21, were developed for the film Tin Toy. 
They illustrate the kinds of special-purpose effects for which 
the shading language is suitable because it encourages writing 
special shaders for special jobs. They form a matched pair. 

The eponymous hero of Tin Toy is a small, very shiny windup 
toy. The film takes place in a room lit by a large, paned picture 
window that casts light in rectangular patches. 

windowhighlight surface 

One would expect the light from the window to produce a 
patchy highlight on the surface of a very shiny object like the 
toy, and that is what windowhighlightO provides. 
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/* 

* windowhighfjghtQ: Give a surface a window-shaped specular highlight . 

7 ' 

surface 

windowhighiight( 

point centers point "world" (0, 0, -4), /* center of the window 7 

in = point "world" (0, 0, 1 ), /* normal to the wall */ 

up = point "world" (0, 1, 0); /* 'up' on the wall */ 

color specularcoior =1 ; 
float Ka = .3, 

Kd = .5, 

xorder = 2, /* number of panes horizontally */ 

yorder = 3, /* number of Danes vertically V 

panewidth = 6, / m horizontal size of a pane 

paneneight = 6, /" vertical size of a pane 7 

framewidth = 1 , /* sash width oevween panes 

fuzz = .2;) /* transition region oevween pane and sash 7 


uniform 



point 

in2. 

/” normalized in 


right, 

/* unit vector perpendicular to in2 and up2 


up2. 

/* normalized up perpendicular to in 


corner; 

location of lower left corner of window 

point 

path, 

incident vector i reflected about normal V 


PtoC, 

/* vector from surface point to window corner 


PtOr; 

•'* vector from surface point to wail along path 

float 

offset, modulus, yfract xfrac:; 

point 

Nf = faceforwardi normalize(N), 1 }; 


/ 


/ 


/* 5er up uniform variables as described above 7 

in2 = normalize 1 inj; 

right = up A in2; 

up2 = normalize(in2 A rignt); 

right= up2 A in2; 

corner = center - nghrxo r der~panewidth/2 - 
up2“vorder*paneheight/2; 

path = reflectn, normalizefNf)); /* trace source of highlight 7 

PtoC = corner - Ps; 

if (path. PtoC <= 0) 1 /* outside the room 7 

xfract = yfract = 0; 

} else | 

r 

'Make PtoF be a vector from the surface point to the wall 
* by adjusting the length of the reflected vector path . 

7 

PtoF = path “ (PtoCJn2)/(path.in2); 
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A 

m Calculate the vector from the corner to the intersection point , and 

* project it onto up2. This length is the vertical offset of the 

* intersection point within the window. 

V 

offset = {PtoF - PtoC).up2; 

modulus = mod(offset, paneheight); 

if; offset > 0 && offset/pane height < vorder ) { inside the window */ 
rf( modulus > (paneheight/2)} A symmetry about pane center */ 
modulus = paneheight - modulus; 

vTraqt = smoothstepl A fuzz a: the edge of a pane 7 

(ira me width/2. - (fuz2/2), 
ftramewidth/2j + (fuzz/2), 
modulus;; 


i else I 

\ Tract 

i 


= 0 ; 


f* Repeat the process for horizontal offset */ 
offset = (PtoF - PtoC). right; 
modulus = mod (off set panewidth); 
if. offset > 0 && off set/pane width < xorder ) ' 
if' mpoulus > (panewidth/2)) 

modulus = panewidth - modulus; 
xi r act = smoothstept 

(framewidth/2) - (fuzz/2), 
(framewidtn/2) + (fuzz/2), 
mod uius. 1 ; 

! else | 
xfracj = 0; 


A specular calculation using the highlight 7 
Ci = Cs * (Md*diffuse(Nf) * Ka*ambient()) 

- vfra<r*xfract*$Decular color ; 

} 

Listing 16.20 Surface shader providing a paned-windozc highlight 


As illustrated in Figure 16.2, the modus operandi of windowhigh- 
lightQ is to follow a ray of sunlight from the surface point back 
to the wall with the window. The center of the window is giv- 
en in the instance variable center , in points perpendicular to 
the wall, and up is parallel to the wall in the vertical direc- 
tion. The horizontal and vertical distance of the backprojected 
point relative to the lower left corner of the window deter- 
mines whether the point hits a pane or the frame in between 
panes, or falls outside the window altogether. In the first case. 
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corner _ 


(PtoF- PtoC). right 

Figure 16.2 Operation of win ao whighlightQ; path is / reflected about 


the highlight is specuiarcolor, in the latter, dark. The smooth- 
step() function is used to provide 2 fuzzy boundary between 
light and dark regions. 

windowhighlightQ shows the power of the dot product and 
cross product operators in the shading language. A few cross 
products are sufficient to set up the orthogonal vectors in2, 
right and up2, which completely describe the window' s loca- 
tion and orientation. Thanks to the definition of cross prod- 
uct, they are correct even if the input vectors in and up axe not 
originally orthogonal. 

The dot product operator is used to project the reflected ray 
PtoF onto the window wall, then to project the intersection 
point onto right and up2. The latter projections completely de- 
scribe the ray's relationship to the panes of the window. 

windowlight 

windowiightQ operates in a very similar fashion. Figure 16.3 
shows the differences between windowiightQ and windowhigh- 
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(PtoF- PtoC). right 


Figure 16.3 Operatigr. of windowlightf): PtoF is parallel tc to-from). 


lightQ. Rather than tracing along the reflected ray from the sur- 
face point Ps, a path parallel to ( to-from ) is traced from Ps. 

Like winoowh ghlightQ, windowlightQ takes advantage of the 
dot product and cross product operators in performing its pro- 
jection to the windowed wall. 

Simple Tricks 

Beyond supporting the development of shaders for special 
purposes, the shading language encourages finding "tricks" to 
make modeling and rendering easier or the resulting appear- 
ance more interesting. In that spirit, shading can often be used 
to add information to relatively crude geometry, giving it a 
complexity of appearance far greater than that of the actual 
model. The fact that shaders are often independent of the un- 
derlying surface means that one shader can serve across many 
different models with no more effort than it takes to call Ri- 
SurfaceQ. The speed and ease with which useful shaders can 
be developed also adds an element of fun at the same time. 
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/' 


* windowlightO: Cast patches of light as through a paned window. 

*/ 

l 

light 


ndowlightl 

point from 

= point “world" { 0, 0, -20), 

to 

= point “world" (0, 0, 0), 

center 

= point "world" (0, 0, -4) y 

in 

= point "world" (0, 0, 1 ), 

up 

= point "world" (0, 1, 0); 

color iightcolor 

= color (1 , .9, .6). 

darkcolor 

= color (.05, .2, .1); 

float intensin 

= 1 , 

xorde r 

= 2, /* number of panes horizontally 

vorder 

= 3, /* number of panes vertically 

panewicsth 

= 6, /* horizontal size of a pane 

paneneight 

= 6, /* vertical size of a pane 

fra mew idth 

= 1, M sash width oe tween panes 

fuzz 

= .2:) /* transition region between pane and sash 

uniform 

point in2, 

'* normalized in 

nght. 

M unit vector perpendicuiar to in2 and up2 

up2, 

'* normalized up perpendicular to in 

comen 

'** location of lower left corner of window 

path: 

direction of sunlight travel 

point PtoC, 

* vector from surface point to window corne r 

PtoF: 

'* vector from surface point to wall along path 

float offset, moculus, 

, vfract. xfract; 


point Nf = faceforwardi N, ] 


f* initialize the uniform variables */ 
path = (from - to): 

in2 = faceforwardt normaSizef in), path); 

right = up A in2; 

up2 = normalize 1 in2 A right); 

right = up2 A in2; 

corner = center - r!ghrxorrier*panewidth/2 - 
up2~vorder*paneheight/2: 


soiar( -path, 0.0 ) I 
PtoC = corner - Ps; 

if ipath.PtoC <= 0) 1 /* outdoors => full illumination *f 

xt'ract = vfract = 1 ; 

) else | 

r 

" Make PtoF be a vector from the surface point to the wall 
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*/ 


by adjusting the length of the reflected vecto r path. 


PtoF = pajth * (PioC.in2)/(pathJn2); 


f* 


* Calculate the vector from the corner to the intersection point, and 

* project it onto up2. This length is the vertical offset of the 

* intersection point within the window. 

V 

onset = (FtoF - PtoC).up2; 

modulus " mod ( offset, pane height); 

if: offset > 0 && otfset/paneheight < yorder ) { /* inside window 7 
if modulus > tpaneheight/2)l 

modulus = paneheight - modulus; 
vfraci = smoothstep: 

'fra me width 2) - ( fuzz/2 ), 

(frarjnewidth/2) - (fuzz '2;, 
modulus); 

I else { 

vfract t 0; 


symmetry in pane 
include sash fuzz 


Repeat for 
onset = 
modulus = 
if offset > 
if moc 


fPloi 

r 

0 
u 

moqu 
xt r act 
iTran|)< 
(Tram* 

modp 

I else { 

xfract 


Cl = intensity 


I 


Listing 16.21 light 


horizontal offset * f 
k - PtoC). right; 
modtoffset. panewidth); 

&£ offset/pa newidth < xorder > ( 
I us > (pane width/2)) 
iius = panewidth - modulus; 
smoothstep: 
lewidth.CM - (fuzz/2 ) ; 

>ewidtn/2; + (fuzz/2), 

I us/; 


* mixi darkcolor, lightcolor, /tract* xfract); 


fnader simulating sunlight through a window 


easysurface 

A simple yet useful surface shader is shown in Listing 16.22. 
easysurface () is a surface shader that gives objects a color with 
information con:ent even without any light sources declared 
in the scene. Up to now, the only way to view a surface with- 
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out any light sources has been to use the "constant" shader, but 
that method makes only the outline of the surface visible (as 
did providing only ambient lights). easysurfaceQ gives each 
surface a uniform color, but varies the intensity with the ori- 
entation of the surface, dropping it to 0 as the surface faces 
away from the camera. The effect is as if a distant light had 
been placed at the origin of camera space. 


r 

'easysurfaceQ: orientation-sensitive surface shadins without a iieht source 
V 

surface 

easvsunacei 

float Kd = .8, 

Ka = .2, 

failoff = 2.0 ) 

{ 

float diffuse • 

diffuse = I.N ' I J * N.N); 
diffuse = povvidiffuse, rail off); 

Ci = Cs * Ka - Kd * diffuse ) ; 


Listing 16.22 Surface shader for use without a light source 


edge-rounding displacement 

The roundO displacement shader shown in Listing 16.23 can 
be used to ease the hard-edged appearance of some adjoining 
surfaces by beveling the joint. It w’orks by displacing the sur- 
face of a bilinear patch according to the distance from the edge 
of the surface. It puts a nice round edge on the joint if two 
patches meet at a 90 degree angle. 

roundO works as follows: call the joint beriween the displaced 
and undisplaced surface the inflection edge . For surfaces joined 
at a 90 degree angle, which we assume here, there is an inflec- 
tion edge exactly radius distant from each surface edge. A sur- 
face point needs to be displaced if it is beyond an inflection 
edge (it is less than radius in distance from some edge). 
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— 


r 


* round*?: d;sp\ 

see the edge of a bilinear patch so that, if it is placed next to 

w another patch at a right angle., the edge will be rounded . 

m/ 


displacement 


round( 


float rad 

j 

us = .10 ) 

1 

float uu| 

/' distance in u to the nearest “ vertical " edge w/ 

vvj 

t distance in v to the nearest " horizontal " edge 

lu, 

r ' real " distance to the nearest “vent cal" edge 

Iv: 

/' ,: real h distance to the nearest " horizontal " eoge 

point cer 

ter, point toward which the surface is displaced 

Gp( 

lu , /' dPdu pointed toward pater, center line 

cp: 

3v; /' dPd\ pointed toward pater, center line 

Find the 

distance in parameter space from the nearest edge in 

u anc ir 

\ and the directions awa\ from those edges. 7 

if lu < ,5 

- 

uu = 

= u* 

aod 

t = dPdu. 

else 


uu = 

: ", - U 

000 

I 

■j - -dPdu- 

i 

if < .5 1 


VY = 

: K ; 

coo 

\ = riPov; 

i eise 1 


VY = 

: ' ‘1' 

opo 

v = -dPdv; 


Find the dt stances from the edges in the current space. M/ 
lu = length t' d^Ou 'uu); 
i\ = length i dPoy*v\ ?; 

if (lu < radius I Iv < radius) | /* only if within radius of an edge... V 

/* 

* Find the point towards which the surface point will be 

* moved. This center is on the center line of a cylinder, if we 

* ar$ not near the corner of the patch , or is the center of a 

m sphere , if we are. We move 'center' to the nearest inflection 
' edge along u and/or v. 

*7 

center = point{0,0,0); 
if (lu < radius) 

center = (radius-lurnormaiize(dpdu); 
if (Iv < radius) 

center += (radius-lv)"'normalize(dpdv); 



Chapter 1 6: A Gallery of Shaders 








PLATE 2 Shader show_xyz() (see Listing 16.13) applied to a light bulb 





* 



PLATT 3 fen run-- spread for Dr. Dobb's Journal executed using shader screen() 
(Listing 16 on the teapot at bottom , eroded)) (Listing 1617) at right , and 
b}ue_rr r artylefj (Listing 1619) on the teapot in the middle 



PLATE 4 Use of shaders woodO (Listing 1615) on the near elephant, dented() 
(Listing 1616) on the middle , blue_marble() (Listing 1619) on the far ele- 
phant, granite) (Listing 1618) on the pedestal, and the shadowed spotlight 
ghadowspotf) (Listing 1633) as two of the light sources 



■ 





PLATE 5 Frame from the film Tin Toy showing a window-shaped highlight on 
the surface rendered using the windowhighUghk) shader (Listing 16.20) 



PLATT 6 Another frame from Tin Toy showing solar light cast by a window us- 
ing the windowlightO shader (Listing 16.21) 















PLATE 8 Close-up of the light bulb filament, showing the effect of using shaders 
filamentf) (Listing 1625), giow() (Listing 1626) and droopO (Listing 1627 1 









PLATE 11 Three light bulbs rendered as: copper using the metaK) shader 
(Listing 16,3) at left , textured plastic with txtplasticO (Listing 1629) in middle, 
and a pitted metal surface displaced with pitsO ( Listing 16.30) at right 







PLATE 12 Chi 
pin^colorO iTis 





















PLATE 17 Three pencils. Each pencil uses rubberO (Listing 16.38) for the eras- 
er, embossO (Listing 16.36) to displace the label and sdixonO (Listing 16.37) 
to color the label On the pencil at left, the ferrule was given a flat color, in the 
middle a texture was used, and on the right, dferruieO (Listing 16.35) was used 
to provide the ridges. 


\ 




tv- i !.» *'*' -WH! 




PLATE 20 Guitar modeled by CADKEY and rendered with Rende^Man using 
a reflection map 



PLATE 21 Cover for "MacWorld" magazine , modeled by TASC and rendered us- 
ing Render Man 




I 

i 

i 

\ 

I 

i 

i 



Copyrighi National Geographic Soo«y 1989. Ali rights reservec. 


PLATT 22 Exploding globe for National Geographic 






[ 



PLATE 23 Stereo pair of cover image 



PLATE 24 Stereo pair of Luxo Jr . 



PLATE 25 Stereo pair from Knickknack 


The plates above are stereo pairs, which can be viewed directly. Place the book 10 
inches from the eyes, and relax the eyes as if staring into the distance. It may help to 
place a vertical divider extending from between the stereo images to the tip of the 
reader's nose. 







A Move center perpendicular to the surface ’/ 
center += P - radius*normalize(N); 

A Make P be distance 'radius' along the line from 'cented to P */ 
P = center - radius'normalize( P-center ); 

) 

N = calcuiatenormal®; 

) 


Listing 16.23 Displacement shader for bevelling perpendicular bilinear patches 


Exactly radius beneath the inflection edge runs the center of a 
cylinder around which beveled points need to be wrapped. 
Two surfaces adjoining at a 90° angle will have coincident cyl- 
inder centers, so the cylinder points will join smoothly. 

The shader wraps the surface around the cylinder by project- 
ing points on the surface toward the center line until they are 
radius away. Figure 16.4 illustrates. Tne point on the center 
line ( center ) to project tow-ard is found for each surface point 
bv moving P perpendicularly to the nearest inflection edge 
(using dPdu, - dPdu_ , dPdv or - dPdv as appropriate), then drop- 
ping radius in distance below the surface along the surface nor- 
mal. 

The results of using roundO are shown in Figure 16.5. This 
shader is less generally useful than many of the shaders in 
this chapter. It is included here largely to demonstrate this par- 
ticular possibility for a displacement shader. It w r ouid be fairly 



Figure 16.4 Rounding a surface corner 
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Figure 16.5 round applied to e cube 


straightforward to extend it to work for non-perpendicular 
joints and other widths and shapes of joint. Any geometric in- 
formation about adjoining surfaces and their angles would, of 
course, have to be provided in instance variables. 

threads displacement 

The following four shaders were written for the light bulb 
seen in Plate “. The first, threadsQ, is a displacement shader 
that turns a cviinde: into a threaded base for a light bulb. It 
takes four instance variables: frequency controls how many 
threads appear per unit of texture parameter t; amplitude 
gives the maxiinum displacement; phase "turns" the threads; 
offset provides a base displacement; and dampzone provides 
damping at the ends so the cylinder still presents a circular 
opening. 

The first line o: threadsQ calculates a displacement from the 
surface as a phased sinusoid, t is used for the modulation 
lengthwise along the cylinder, and s provides a phase factor 
so that the threads really do spiral. Normally the modulation 
is centered around the actual surface, but offset may be used to 
modify that. 
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A 

' threadsO: wrap threads around a cylinder 
V 

displacement 

threads { 

float Km = .1 , 

frequency =5.0, 
phase = .0, 
offset = .0, 
dampzone = .05 ) 

( 

float magnitude: 

A Calculate the undamped displacement V 

magnitude = (sin P!*2"fi*frequency «•- s - phaseD-offset; ’ Km; 

A Damp the displacement to 0 at each end V 
iff t > (1 -dampzone)) 

magnitude '= 1 .0-t) / dampzone: 
else iff t < dampzone ) 

magnitude “=t dampzone: 

A Do the displacement */ 

P -= normalize * magnitude: 

N = calcuIatenormal f P); 

f 

Listing 16.24 Displacement shader providing light-bulb threads to cylinder 


Before perturbing the surface, the magnitude of the perturba- 
tion may be scaled down, or damped, to 0 if the point to be per- 
turbed is near one end of the cylinder. This provides a perfect- 
ly circular interface so other round shapes like the light-bulb 
glass can be joined with the threads. 

A close-up of the threaded cylinder is shown in Plate 9. This 
object dramatically illustrates the distinction between shape 
and shading. Specifying surface geometry with the same ap- 
pearance is far more difficult than applying this shader. 

filament 

The second shader from the light bulb is shown in Listing 
16.25. filamentO is like a combination of screenQ and 
threadsO . It turns a cylinder into a spiral filament. As shown 
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in Plate 8, the filament can be brought to a point by applying 
the same shader to two cones at the ends of the cvlinder. 

In filamenfO, the frequency and phase instance variables are 
identical to those of threadsQ. width specifies the fraction of 
the surface to be covered by the filament, and is used to 
threshold the distance of each point from the edge of the fila- 
ment. Since the filament is self-illuminating, the output sur- 
face color is alwavs Cs. 




* rilamentO: mac c \ 

itarneij-Hke spiral onto the surface o: a cylinder. 

surface 

filament 

float rrec jent 
phase 
width 

~ 5.0, 

= 0.0 
= 0.3 

i 

Calculate me distance of ($,t) from a spiral as a fraction [0,1] V 
float offset = mod :t x 'reajenc\ + phase), 1 .0;; 


Thresnoid ne fraction against the fractional filament width */ 
if iofr’se: < width, i 
C = Cs: 
o, = • 

1 else 

G = 0.0: 

Oi = o.o- 

) 



Listing 16.25 Surface skade v ic make a cylinder look like c filament 


glow surface 

When the filament is rendered using only filamentQ, some- 
thing seems to be missing. Its geometry is more interesting 
than a simple cylinder, but it is shaded as a simple constant- 
colored surface, whereas a real filament would be glowing. A 
glow can be imparted (see Plate 8) to this filament by sur- 
rounding it with a sphere shaded appropriately. The glowQ 
shader shown in Listing 16.26 does the trick. 
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Figure 16.6 "Directness of view " on filament corresponding to " obliqueness of 
view" on surrounding svhere 


A glow is brightest when looking directly at the glowing ob- 
ject, and falls off rapidly nearby. If the glowing object is cen- 
tered inside a sphere, then closeness of view’ to the object cor- 
responds to directness of view on the sphere. Figure 16.6 
shows that relationship. glowQ diminishes the opacity’ of the 
sphere (brightness of glow) according to the obliqueness of / as 
measured by its angle with N, 


/* 

9 glow(): a shader for oroviding a centered "glow" in a sphere 
*/ 

surface 

giow( float attenuation = 2 ) 

I 

float faJloff = l.N,; /* Direct incidence has cosine closer to 7 . '/ 

if (failoff < 0) ( A Back of sphere only */ 

/’ Normalize failoff by lengths of I and N */ 
failoff = failoff “ failoff / (LI * N.N) ; 
failoff — powifailoff, attenuation); 

Ci = Cs * failoff; 

Oi = failoff; 

) else 

Oi = 0; 


Listing 16.26 Shader mapping object-space coordinates to colors 
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The obliqueness of view on the sphere corresponds to the dot 
product between the surface normal vector K. and the inci- 
dent direction t glowQ takes that dot product (between 0 and 
1), raises it to the power attenuation, and uses the result to set 
both the color apd opacity of the sphere. 

In Plate S, the glow is oblong; this effect was achieved bv scal- 


ing the sphere 
of the filament. 


droop displacement 


The last shade: 
the filament of 


non-uniformlv, elongating it along the length 


seen in the light bulb concerns the fact that 
a real light bulb bends with gravity. Therefore, 
the displacement shader droopO is used to provide a catenary 
droop to both the cylinder of the filament and the surround- 
ing sphere. For purposes of drooping, "down'' is assumed to 
be in negative v. in shader space. 


r 

’ droop!): a dispiacdrn< 
7 

^define M_E 2 

displacement 
droop ( 

float Km = 0.05 


ent shader for making a surface "sag' along !. 
62818264590432354 A e V 




3 

■i 


float droop, vDel; 


i 


droop = (t-.5:’ r 2j; 


A t in 10,1 j goes to droop in hi, 11 */ 


vDel = *Km * ( kE + 0/M_E) * texp(droop)-**exp(-droop)) ); 
setycomp(P, ycomp(P; + yDe!}; 

N - calculatenormal(P); 


Listing 16.27 Displacement shader with catenary droop in y 


The surface is assumed to be supported at its extremities in t, 
which for a cylinder and sphere are the ends and poles, respec- 
tively. The translation of P is strictly in y, and is 0 at the ends. 
In between, the droop is scaled by the Km instance variable. 
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Texture Mapping 

As outlined in Chapter 12, the texture mapping facilities of 
RenderMan provide control over a wide variety of surface at- 
tributes. However, the subject really opens up only when one 
begins to write shaders. This section presents mapping shad- 
ers for all occasions. 

Texture 

The most basic kind of map is the texture map. Since the ac- 
cess functions are defined as part of the shading language, 
they can be used in any kind of shader, but they are most use- 
ful in surface and displacement shaders, and to a lesser extent 
in light sources. 


slide projector light 

A light source shader can provide dramatic variations in light- 
ing across a scene because it has access to surface locations and 
the location and direction of the light source itself. This capa- 
bility meets texture mapping in the shader slideprojectorO, 
shown in Listing 16.28. The slide projector is shown in action 
in Plate 10. 

The interesting instance variable in slideprojectorO is field- 
oiview, giving the angle over which the projector casts its im- 
age. A small field of view makes the image smaller at any dis- 
tance, and makes it more difficult to aim. 

The from and to instance variables give the location and direc- 
tion, respectively, of the projector. The up variable deter- 
mines the orientation of the projection. Rather than depend 
on instance variables to specify the location and direction of 
the light source, slideprojectorO might have located the projec- 
tor at the coordinate origin pointing along the z axis and let 
the source be positioned by the modeling transformation. 

As shown in Figure 16.7, slideprojectorO casts an illuminate 
cone that is wider than fieldofview by sqrt(2), to make it en- 
close the entire image. Within the illuminate statement, sloe 
and tloc essentially represent a perspective projection of the 
surface point relative to the light position, direction, orienta- 
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i 


up 

A 



non and field of view. relT, relU and relV are mutually orthog- 
onal vectors pointing in the light source direction and hori- 
zontally and vertically (in the u and v directions) on the slide, 
respectively. Given the vector L from the location of the pro- 
jector to the surface point Ps. the dot product L relU projects 
Ps along the u direction, and LrelV the v direction. Pt is the 
dot product L IrelT, which represents the distance of the sur- 
face point along the projection direction. Pt is used to provide 
the perspective by scaling the projected horizontal and verti- 
cal distances Lre/L/and LrelV. 

The -1 to -1 range of values of sloe and tloc is mapped into 
the range [0,1] for indexing the texture. .AT textures in the 
shading language are indexed in this range regardless of their 
resolution. Some Ps may yield sloe and iloe outside the inter- 
val [-1,1], and therefore index the texture outside [0,1], but the 
textureQ function will handle them correctly by returning 
black. 

The texture map is accessed by calling the function textureO, 
passing it the texture map name which was passed to the shad- 
er in the si i dename string instance variable. textureO also 
takes the floating-point coordinates indexing the map and re- 
turns a color, the color of the texture at that point, filtered to 
eliminate aliasing. 
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•i'-frUJi** ‘it V-Htoi -*->*!* k ***>-'*>’ 


/* 

* slideprojector(); Cast a texture map into a scene as a light source 
*/ 

light 

slideprojector( 

float fieldofview=Pl/32; 
point from = (8, -4, 10), 

to = fQ;0,0), * - 

up = point "eye” (0,1,0); 

string si idename = 

shadowname = ) 


uniform point relT, /” normalized direction vector 

relU, r "vertical" perspective of surface point 
re!V; /* "horizontal 11 perspective of surface point */ 
uniform float spread = 1 /tan{fieidofview/2); f* spread of "beam" 
float Pt, t projection of Ps on re!T t distance of 

surface point along light direction ) 

Pu, /* projection of Ps on relU 

Pv, /* projection of Ps on relU 

sloe, tloc; r perspected surface point 


/* initialize uniform variables for perspective */ 

relT = normalizes - from); 

relU = re!T A up; 

re!V = normalize' reiT A relU); 

relU = re!V A reiT; 


illuminateffrom, relT, atan<sqrt(2)/spread)) I 

L = Ps - from; /* direction of light source from surf, point “/ 

Pt * L.reiT ; /* coordinates of Ps along relT , relU, relV V 

Pu = L.reiU; 

Pv = L.relV; 

sloe = spread" Pu/Pt; /* perspective divide V 

tioc = spread"Pv/Pt; 

sloe = sloe" .5 ^ .5; /* correction from f-h 1} to 10,1] */ 

tloc = tloc". 5 + .5; 

G = color textureislidename, sloe, tloc); 
if( shadowname !* "" ) 

G "= 1-shadow(shadowname, Ps>; 

I 


Listing 16.28 Slide-projector light source shader 


This shader also uses a shadow map, since it would be strange 
for the same point on a projected image to project onto more 
than one surface. This last is indexed by surface point Ps and 
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I 




uses a depth map to determine to what extent that surface 
point is obscured from a light source. shadowO returns a 
"shadow fraction" suitable for scaling the projection color, 
which is done here. 

txtplastic surface 

Listing 16.29- shows a simple surface shader using a texture 
map. txtpiastipQ is a revised version of the standard plastic 


shader. Instead 

of the surface color Cs passed by RiColorO, tx- 

tplasticO uses a 
flection. 

texture map to provide the surface's diffuse re- 

/ 

* txtpiasticO: ve r sion of plasticQ shader using an optional texture map 

7 

surface 

txtplastic* 


float Ks 

= .5, 

Kc 

= .5, 

Ks 

= 1, 

rough riess = .1 ; 

color specui; 

ircoior = 1 ; 

string rnaonalne = uu ) 

/ 

t 

point NT = faceforward: N, ] ); 

if( map name 1 

t m ) 

Ci = color texturet mapr.ame J; /* Use s and r * 

else 


G = Cs 


Oi = Os; 

Ci = Os* 

J 


(Kc'ambientO + Kd*diffuse(Nf)) 


-r SDecuiarcolor * Ks * specular(Nf,-l, roughness j; 

) 


Listing 16.29 Plastic surface shader using a texture map 


Plate 11 shows three light bulbs. The upper left bulb is given a 
simple copper appearance using the standard metalQ shader. 
The middle bulb was shaded using txtplasticQ. 
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Bump mapping 

The third light bulb in Plate 11 provides an interesting varia- 
tion on the theme of texture mapping. In the pitsO shader, the 
value in the optional texture map is used to displace the sur- 
face. The fact that the surface is actually being displaced (as op- 
posed to simply manipulating the normal) is shown in the 
bulb's profile. The texture used in Plate 11 is shown in Plate 
13; it was also used in the bov/ling pins on the cover and in 
Plate 12. 


/* 

' pitsO: use a texture map to appiv pits to a surface 
V 

displacement 

pitsf 

float Km = 0.03; 
string marks = 

{ 

float magnitude; 

/* Cet the displacement . if an v, from the texture mao. ' 
if( marks !* “) 

magnitude = float texture(marks); * Use s, t */ 

else 

magnitude = 0; 

/* The texture determines the size of the gouge , scaled by Km. V 
P ts -Km a magnitude * normalize(N); 

N = calculatenormal(P); 

I 

Listing 16.30 Displacement shader using a texture for pits and gouges 


Bowling pin surface 

Plate 12 shows one of the bowling pins on the cover. Listing 
16.31 shows the surface shader used on the bowling pins. It 
starts by dividing the height of the pin into different-colored 
areas, coloring the base gray, applying a neutral color to the 
body and top, and using a procedural texture for the red trian- 
gles on the neck. 

pin_color() then checks the surface point against a series of 
bounding boxes. If the surface point is within a bounding box. 
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a texture associated with that box is applied. The "coated plas- 
tic/' "ABC cxcle" and "Brunswick B" labels, shown in Plate 
13, are all applied this way, normalizing surface points within 
the bounding boxes. If the texture coordinates that come out 
of the normaization are outside the range [0,1] (ie., the points 
lie outside the bounding box) the textureO function will re- 
turn black (0) 

Finally, the dirt and gouges, contained in the texture map 
“marks.txf and shown in Plate 13, are applied to the pin. The 
instance variable spin is used to rotate this texture with re- 
spect to the labels so that each pin appears different, 
“marks.txf must have been created to be cvclic so that accesses 
outside the range [0,1] wrap around. 


r 


DR 


* pin_coior{i: St ade a bowling pin with color , labels, and marks . 
V 

color (0.6,0.05.0.05 
color (0.6,0.05,0.05) 
color (1.0, .8, .4) 
color (.3, .3, .3) 
color (.0,.0,.9) 


^define REDCOL 
^define CIRCLECDLOR 
??define NELTRA .COLOR 
^define GRAYCCLOR 
^define BLUECO.OR 


A Bounding box 
^define x! Mi\ -( 
^define xlMAX 
^define vl MIN 
^define y! MAX 


n rexture space for " ABC Circle " label 1 
.25 
$.45 


A Bounding box r texture space for " Coated Plastic " label */ 
^define x2MIN -1 .1 
£oef ine x2MAX 1 .1 
^define v2MlN 6A 
^define y2MAX 8.6 


A Bounding box 
^define x3MlN -1 
^define x3MAX 1 
# define y3MIN 6 
^define y3MlD 6 
^define v3MAX 


surface 

pin_color( 

float 


Ka 
Kd 
Ks 
rougfli 
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'* red band on neck 7 
"... for " circle “ label V 
A., tor bodv 
A-.- for base V 

"... for "Brunswick” */ 


/|n texture space for "Brunswick B” label V 
3 
.3 
0 
55 
.6 


ness 


= .5, 
= -5, 
= . 8 , 
* . 1 , 
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spin = 0; 

color specularcolor = 1 ; 
string texturename = "marks.txt" ) 

float strength; 
point Nf; 
float x,y,z; 
color cs ; 


Nf = faceforward{ normalize(N), { }; 
x = xcompftransform( ,, obiect' , / P)); 

y = ycomp(transformf ,l object" > P)); A Pins are 75" tall V 

2 = zcomp(transform( n object H ,P)); 


if (v <= 0.25 - cs = GRAVCOLOR; A gray base 

else if (v <= 9.5 ; cs = NEUTRALCOLOR; A neutral body 

else if ty <= 1 0.5) cs = REDCOLOR; red ring 

else if (y > 1 2.0 » cs = NEUTRALCOLOR; A neutral top 

else 1 ~ A between ring and top. create red crown 

u = (u-k2<*6; u = u-fioor(u); 
if tu < .5) 

if (2“u - 0 > (y*10.5)/(l 2.0-1 0.5)) 
cs = REDCOLOR; 

else 

cs = NEUTRALCOLOR; 

else 

if *.2 \j - 1 - <v-10.5j/(l 2.0-1 0.5) < V. 

cs = REDCOLOR; 

else 

cs= NEUTRALCOLOR; 


*/ 

*/ 

V 


if {z < 0) ■" on the back side V 

A Co fetch the “Coated Plastic" label. This is a single * 

* channel texture that we want to appear black. 
cs = cs * tl - float textureC'coated.txT', 
(x-x2MIN)/(x2MAX-x2MIN), 

1 .0 - (y-y2MIN)/(y2MAX-y2M!\) /); 

else 1 A on the front side V 

A Co fetch the “ABC circle " label. This is a single- 
K channel texture that we want to appear red. */ 
strength = float texturercircle.txf, 

1 .0 - (x-xl M|N)/(x1 MAX-xl MIN). 

1 .0 - (y-yl MIN)/(y1 MAX-yl MIN)); 
cs = mix(cs,ORCLECOLOR,strength); 


A Go fetch the " Brunswick B" label. This is a single - 

* channel texture that we want to appear red at the bottom 

* and blue at the top . */ 
strength = float texture{“b.txt", 
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1 .0 - (x-x3MIN)/(x3MAX-x3MIN), 

1 .0 - (v-y3MIN)Ay3MAX-y3MIN)); 
if (y > y3MID! 

cs = mixfcs.BLUECOlOR.strength'; 

elie 

cs = mixtcs,REDCOLOR, strength); 

I 

& 

/ 

' Now far the dirt and gouges. Look up in a single channel texture 
” for the\ din applied to the surface . Spin the texture different i\ for 
m each pin so that tne similarity is not apparent. This same access is 
m made in the displacement shader to align the gouges with the din. 

strength = R - float texturet texturena me .s+SDin.v" 5.0'?; 
cs = cs * stfengtn : 

* Now that cs has Deer; set. perform the standard plastic shading 
' calculation */ 

G; = 1.0; I 

G = cs * (K£ fc ambient: ~ Kd k diffuse(N f f)i 

- Ks^specuiarcolo^specularfN^normalize roughness}; 


Listing 16.31 Surface shade r for a bowling pin 


bowling pin bump map 

For the greatest realism in the bowling pin, the displacement 
shader gouge 0 is also used. It also applies the "marks.txt" map, 
but uses it to displace the surface so that it really appears dent- 
ed. The instance variable spin should be the same as for the 
corresponding Cali of pin_color(), to synchronize mark with 
dent. The variable Km scales the magnitude of the texture 
map values to provide the actual displacement. Plate 12 de- 
picts the bowling pin. 

Shadow-mapped spotlight 

The next shader shows a simplified use of a shadow map. 
shadompotQ, shown in Listing 16.33, is just the standard spot- 
lightQ shader modified slightly to use an optional shadow 
map. In fact, the modification involves the addition of only 
three lines. An instance variable, shadowname, is added and 
set to the empty string. Just before setting C[, the string is 
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/* 

*gouge(): Use a texture map to displace a surface. 

V 

displacement ' 
gouget 

float Km = 0.03, 

spin =0.0; /* each pin gets its texture spun */ 

string texturename = "marks.txt") 

( 

float y = ycomp(transform(“objecf',P)); /* convert to object space '/ 

/* Use the same texture map that the surface shader uses. Spin it a different 
* amount for each pin so that similarity is not detected. The texture 
’ determines the size or' the gouge. Multiply by the Km factor, then 
’ displace the surface point inwards bv that amount. 

P -t-= (-Km ‘ texture<texTurename.s+spin,y/15.0)) ” normalize(Nt; 

■N = calculatenormal'P; : 


Listing 16.32 Displacement shader for beating up a surface truth, a texture 


checked. If it is not empty (because it was set when the shader 
was instanced), the corresponding shadow map is used to 
modify the light's attenuation. 

The main point here is that the value returned by shadowO 
gives the extent to which the surface point lies in shadow, a 
value between 0 and 1. Therefore, its return value is subtract- 
ed from 1 to get the extent to which the point is illuminated. 
In -shadowspotQ, attenuation is scaled by the latter amount. 


Environment-mapped surface 

Plate 15 is the result of using a reflection map. Plate 14 shows 
the set of images used as input to the reflection map. The 
shader shinyO, in Listing 16.34, shows how reflection maps are 
actually used. 

shinyO is basically a standard metal shader with a few lines 
added to access the reflection map. After checking that a map 
has been passed to the shader, the vector D is set to the inci- 
dent vector r l reflected about surface normal N. Note that Nf is 
normalized, as reflectQ expects. 
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rule 0 displacement shader, shown in Listing 16.35. 


A 

* shadowsDorO'- spotlight with an optional shadow map 

V 

light 

snadowspoK 

float intensity 
color iigmcolor 
point from 
to 

float coneangle 


= 1 ; 

= point 0, 

= point (0,0,1); 

= radians 30), 
conedeitaangie = radians(5); 
oeamdistributior, = 2; 
string sr.adtovvfiie = ) 


A light position V 


uniform paint 
uniform float 

float 


F direction 


A = (to - from) / length (to - from;: 
cosoutside= coslconeangie), 
cosinside = cos(coneangle-conedeitaangle); 
attenuation, F falloff from center of illumination cone 
cosangle' F cosine of angle wrt cente- of cone 


illuminate, from, A, coneangle { 

cosangle = LA / length (L); F A is already normalized "/ 
anenuation = powtcosangle, beamdistribution (L.L); 
attenuation *= smoothstep cosoutsiae, cosinside, cosangle ); 
if s.napowrile != M,t } 

attenuation *= n .0 - shadows shadovAile. )); 

C! = attenuation * intensity * lightcoior; 


Listing 16.33 Svoilighi using shadow map 


The reflected vector D is transformed to the world space of 
the scene for passing to the environment!) function. It is criti- 
cal that the map be indexed in the same space in which it was 
created, translations aside. Here we use “world" space under 
the assumption that the axes of the current world space are 
parallel to those that applied when the environment map 
was originally rendered. This is why, in Listing 12.3, the only 
rotations performed in setting up the environment images 
were those required to look at the cube faces, so that the axes 
of the cube were parallel to those of world space. As long as 
world space doesn't change, a scene that includes an environ- 
ment map may be viewed with any camera. 
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surface 

shinv( 

float Ka = .3, 

Ks -= .8, 

roughness = .05; 
string mapname = "" } 

f 

color ev; 
point D, Nf, Nl; 

Nf = faceforward( normalize! N), ]); 

Nl = normalizefl); 

if( mapname != | 

/* compute the environment index direction , D “ 
D = reflect(Nl, Sir. 

/* convert D to environment space. */ 

D = transformiVorld" point "world" (0,0,0) - D ; 
ev = environmentimaoname, D), 

I else 
ev = 0; 

Oi = Os: 

Ci = Oi * (Ka * ambient! - 

Ks * (ev * specular' Nf, -Nl, roughness.)*).; 


Listing 16.34 Metal shader with optional environment mav 


A Case Study: One Perfect Pencil 

This section illustrates the results of an attempt to render a 
particular object with the greatest realism. The pencil in Plates 
16 and 17 used CSG for modeling, plus a variety of displace- 
ment and surface shaders. The middle pencil in plate 16 at- 
tempts to hew as close to reality as possible, wTiile the outer 
two substitute other shaders to amusing effect. The most inter- 
esting of the shaders used in the middle pencil appear below. 

ferrule 

The ferrule of a pencil is a ribbed cylinder. The ribs could be 
modeled with partial tori, but an alternative is to use the dfer- 
ruleO displacement shader, shown in Listing 16.35. 
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A 

' drerruieO: Deform the cylinder that models the ferrule of a pencil . 
" The shader adds four ridges that circumscribe the cylinoer and 
* many more between the innermost ridges that are parallel to 
9 the cylinder axis. The ridges are displaced sine waves. 

9 The ferrule is also slightly flared at the eraser end. 

V 

^define UFREQ 21 9.91 1 
^define VFREQ 1 04.72 
^define RIMIN' h 7 
^define R1 MAX Ion 
£ define R2MIN 
^define R2MAX 
^define R3 MIN 
* define R3MAX 
=define R4 M!n 
^ define R4M.AX .|83 
displacement 
dferruie' 

float K rr, =1 .005 


f 1 

^ 37 


169 


: 


K, , 


float magnitude = 0; 

A Commute the distance tne sunace should be d'.sp.acec 
if <y <= .02) A the eraser-end flair */ 

nagnituae = 2*0 - sin,78.54*y)); 

if Uv >= R1 jut IN' && tv <= R1 MAX)) A first circular ridge */ 

magnitude = 3*0 - cos'VFREQ’tv-RI MIN')J , 
else if \ y R2MIN, <S (y <= R2 MAX)j A seconc circular ridge V 
magnitude = 3*0 - co$fVFR5Q*{y-R2MIN))); 
else if (<v >.B7] && (v < .63)) A the longitudinal ridges V 

magnitude = -sin(UFREQ“u> - 1 ; 

else if Uv >= R3 MlN's && (y <= R3MAX)’i A third circular ridge */ 
magnitude = 3*0 - cosfVFREQ*!y-R3M!N r ))j; 
else if Uy >= R4MIN) && (y <r= R4MAX)} A fourtr. circular ridge V 
magnitude = 3*0 - cos(VFREQ*(y-R4M!N , ))j; 

A Now apply the displacement in the direction of the normal. */ 

P -r= Km * magnitude * normaiize(Nf); 

A Recalculate the normal. *f 

N = calcuiatenormalfP); 


Listing 16.35 Ferrule displacement shader for a pencil 


The displacement is different for a variety of subranges of sur- 
face parameter v, which runs from 0 to 1 along the lengtfcL_of 
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iheierrule cylinder. This usage is identical tothatofTm 
light bulb shaders, barring any changes to texture coordinates. 
Within -ihe appropriate intervals of v, the displacement is 
based on sinusoids of empirically determined frequency and 
phase. The instance variable Km may be used to exaggerate all 
of the ridges. 


emboss 

The embossi) shader is a general-purpose version of the 
gouge 0 displacement shader of Listing 16.32. The values re- 
turned from the texture access function textureO lie between 0 
and 1. This value is scaled by instance variable Km to yield a 
scalar displacement, which in turn is multiplied by the nor- 
malized surface normal vector to get a displacement vector. 
The surface normal is then recalculated using caiculatenor- 
mal(). 


/• 

*emboss(): emboss a pencil with lettering. It uses the same texture 
M map as sdixont, tc Define the lettering. 

V 

displacement 

embosst 

float Km = .05; 

string texturename= "dixon.tx") 

! 

if( texturename != ,,n> { 

P -= Km * texture'texturename, s, t) * normalizeiN); 

N = caicuiatenormal(P); 

} 

1 


Listing 16.36 Displacement shader embossing a surface using a texture 


This embossing technique is really appropriate only for an an- 
ti-aliased texture, in which pixels at the edge of characters 
grade smoothly between 0 and 1. It works very well for any 
texture with that characteristic. It can be used to give ordinary 
mapped text a striking appe arance jwith ^virtually- 
The highlight on tftfc^Surface of the "Dixon" 1 label on the peiv 
cil shows off its embossing. 
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label 

|_ * =- 

Once the body of the pencil is displaced by the. label it is paint- 
ed by the special-purpose surface shader saixonQ shown in 
Listing 16.37J It uses a label texture map , as in the--et=ft bogsing - 
shader above to control the color of the surface; the texture it- 
self is applied] to the pencil as greerv and the- background- is yel- 
low. But the interesting point is that the texture is also used to 
control the specuiar brightness of the surface. As a result, the 
label appears as metallic green and the rest as matte yellow. 


/. 

* sdixon'i: Paint the body of a pencil. 

SLirrace 

sdixon* 


float 

Ka 

= 1.0, 


Ko 

= 1.0, 


Ks l 

= 1.0, 


rougnness 

= .25; 

color 

green 

= coior(0 .2 


veliov* 

= color,. 56, 

string 

texrj rename 

= '‘dixon.tx" 


point N't = raceforwardtnormalize' N Ji; 
float ink 
color cour 

/' This shader use* a single-channel texture map to apply a 
* mezalhc-greer. ink to a matte-yeliow backgrounc M/ 

A Ce: the amount of ink from texture file. */ 
ink = text ureaexturena me, s, tl; 

A Use ink to mix yellow and green 7 
cool = mixfyeliOvv , green, ink); 

A Compute the output color . Notice that as ink goes from zero to 
one , the diffuse component goes to zero and the specufer 
component is increased. This has the effect of transitioning 
from a matte surface to a metallic one as ink is added. 7 

Oi = Qi: 

Ci = Os * cout * { Ka*ambient() + (l-ink)*Kd‘diffuse(N ! f) + 

mk*Ks*$pecular(NT,norrnaIize{~l),roughness) ) 

/ 

1 I 

Listing 16.37 Pencil-labeling surface shader _ 
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^ r 


rubber 



Xhe.fmairrstitsEfetv“in &te pencil is e 
than using a simple matte-surface-shader,-the shader rubberQ, 
sho wn in Listing 16 .38. includes a. small amount of white dust 
in the surface of the eraser. T he amount of dust i s 



the no{ 

put. 



using scaled surface position points - as m- 


/’ 

* rubberQ: This shader generates a rubber surface. It is a matte shade r that 
' adds in a little white dust to mimic the dust on a new eraser. 

V 

surface 

rubber( 

float Ka = 1 .0, 


Kd 


= 1.5 } 


txtscaie 


point NT = faceforw'ardinormalizeiNiJ), 

Ploc = transformC'shader", P); r Move to shader space * 
color cout, wnite=1 ; 

/* Mix in some white dust . V 

cout = mixiCs white, .05* (noisettxtscaie"Pfoc ); 

/* Compute a matte surface. */ 

Oi = Os; 

Ci = Os * cout * Ka'ambtentO + Kd*dirruse( Nr > ) ; 


Listing 16.38 Rubber surface shader 


Results 


Plate 17 shows what a difference in credibility can be obtained 
by relatively subtle improvements in the realism of shading. 
From left to right the ferrule goes from flat, to textured, to tex- 
tured and displaced (the label and the eraser remain the 
same). The dust on the eraser, the rings on the ferrule and the 
highlights on the label "are all nearly subliminal, but the rig ht- 
hand pencil is mu -eh-nrore credible than theoiher two: — 
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Further Examples 

The remaining color plates are included as examples of imag- 


es using tne 


lender Man Interface. They are included ta-evoke 


some of the possibilities of RenderMan. 


Enhanced CAD 


Plate IS snows a before-and-after pair depicting an open office 
plan' created using Autodesk's AutoCAD™ modeling soft- 
ware. The version at top was rendered using standard shading' 
techniques. At bo’ttom is an image rendered from the same 
scene using the RenderMan Interface to' provide 'shadows, lo- 
cal light sources, reflections from the floor, and a 'variety .of ■ 
textures for the wall, the floor, the pictures on the wall, the 
chair and even some work on the desk. 


Gears 

Plate 19 show' 
show’s 'the qua 
and an accurate 


a set of gears courtesy 


The image 


ofCADKEY 

iitative effects of using smooth curved surfaces 
model of metallic reflection. 



an electric .guitar (also modeled by CADKEY). 
rom the wall are quite subtle, but provide con- 
to the walls. The guitar body itself is com- 


as. 


Guitar 

Plate 20 shows 
The reflections 
siderable dept! 
posed of poiygc : 

Movie carnet 

The movie camera in Plate 21 w r as modeled at The Analytical 
Sciences Corporation and rendered at Pixar. The "Mitchell" 
stamp was debossed using a displacement shader. 

Exploding globe 

Plate 22 is an image produced for National Geographic, a depic- 


tion of a fragile 


earth. This image depended on the' use of par- 


tially opaque materials and accurate textures. 
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V. 


! * m £li i * r Vifi » ' U i * i fir" J7) 0 ~n Z'~ 

The last tiiiee plates show from computer animation 

created using Rende/Man.- Plata ' } Aaa from Luxo~ Jr. in "Light 
Entertainment," an 1989 film from Fbcar, showing the dramatic 
effect- of proper motion blur. Plata. 2 j appears in Knickknack, 
another 1989 Pixar film. The snowtl ikes are individual bicu- 
bic patches. Both the patterned wallpaper .and the wood shelf 
are shaded using procedural textures. 

Finally, Plate P6 shows a special -on: arts shot ho u\ dt :* 1939 
James Cameron film The: Abyss, cxcci ted by tha C/>mp\uer 
i Graphics Group at hidusi/Gl T ‘ig}u uid Ma'y?-a bde p: as con- 
cerns a creature, a, pseudopod fo* uV*d from ceevhu ■■■■•. • line 
Vansparent crealuf a' redacts- an/I its nivl/orm -cu as it 

snakes' through* an 'indr. wat^i diajlm-; dadoim. Tt vvus.oind 
aied using thousa 


iracdoh. 


1 cun a cone wouin 


is of 

bictbic ■* 

J i >J 

r:h a;> 

' *.y! 


pppS = 
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whole f/nr> the modeling 


rv provtcimg. a consis- 


KomdrrMan bhadmu * 1 uinr-v*; 
niques of J - shading 


’ i ’her xendarMan Much- f. >ea s =s i 
world from concerns about rendumr' ,v - w '** A 

rant way to accas.* a variety of rar/ln . n hi u similar wav, the 

i » t -» ‘ * ±r . now \ab nov 1 tcch- 

‘o.ni concarya? i‘:hor of me mouo’ln in- 
volved or the iCndcutug avs/am hi v/hicU they wall be applied. 
The fact that . shad- x S' and texavoi oua •>"* urod in many differ- 
ent Tenderers/ in conjunction with 4 ; panoply of modeling sys- 
tems, provides a- powerful impetus fee the development of 
whole collections* of h mo v a Live cind Lite* rating shading tools. ' 

/Fhe shadeks in tier chapter only . mbs *ha possibilities just 
u; .jiiodyliag syuym-. yovH* <• .V ' 9 c:»vk**v.n /for 'efferent 
of .uv;d .-. -> V n \\ •■■•u* , . . dn biiouH S .e d;v.:lop- 
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APPENDIX A 


Summary of 
RenderMan Program Structure 


Order of Transformations 


Transformations are applied to the points in a scene in the re- 
verse order from which they were called. 

Given: 


G = Points to be transformed 
M = Object transformations 
C = Camera positioning matrix 
P = Perspective matrix 
5 = Screen transformation matrix 
I = Identity 

T = Current transformation matrix 

The illustration below shows how these matrices are applied. 
Applicable notes appear on the next page. 


Set up calls 

RiBegin 
RiProjection 
RiWorldBegin 
Geometry calls 


(Coordinate System) 


(screen space) 


(camera space) - 
(world space) 
(object space) 


Order of 
transforms 


G M ... M | C ... C | P S I 


Order 
of calls 


Points transformed Points transformed 
to world space for through camera &z 
shading. perspective for 

hidden surface. 
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1. At RiBegin the current transformation T is set to identity. 

2. Subsequent transformation calls S apply to T. This allows 
for skewed planes when off-center projections are re- 
quired. Very few people will ever use this. 

3. When RiProjection is called, the perspective transforma- 
tion is multiplied times T and T is then £aved as the pro- 
jection to the screen. T is then set to identity. 

4. Subsequent transformation calls C...C are used to position 
the camera. 


5. At RiWorldiBegin the world-to-camera matrix is set to T, 
and then T is set to identity. 

6. Subsequent transformation calls M...M position objects in 
world space.^ 

The above transformation pipeline transforms objects into 
screen space. The next step, not illustrated above, is to take 
part of the image plane and map onto the raster. 

Begin-End pairs always cause the transformation to be pushed 
or popped. 

RenderMan Program Structure 

The following table summarizes the structure and scoping 
rules of a RenderMan program. The following notes apply: 

1. ObjectBegin-End may happen at any time. If defined with- 
in a FrameBegin-End or WorldBegin-End then it will disap- 
pear after the Corresponding End. 

2. Within FrameBegin-End there may be multiple WorldBe- 
gin-Ends with different display options. This can be used to 
create shadows and environment maps. 

3. WorldBegin-End cannot be nested. 

4. AttributeBegin-End and TransformBegin-End may be nested 
within themselves or each other, and may occur any- 
where including around a WorldBegin-End block to help 
reset matrices. 

5. Note that RiProjection should be called somewhere be- 
tween RiBegin and RiWorldBegin. This call freezes the 
screen mapping, sets up the perspective transformation, 
and sets the current transformation matrix to identity. 
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Summary’ of RenderMan Program Structure 

Scoping 

Scoping Rules 

! Typical Calls In Block 

RiBegin 

j' 

Everything must occur 

i Permanent options for 

i 

i 

i 

i 

between RiBegin-End. 
Current transform set 

ihiders and display. 
‘Permanent attributes, 

1 

to identity. 

light sources and 



retained objects. 

i 

| 

i 

t 

No Geometry (except 
in retained objects). 

RiFrameBegin 

Pushes options, attri- 

(Camera transform setup. 

» 

l 

1 

1 

i 

1 

butes and transformations. 

'Options. 

Attributes constant for 
! frame. 

RiMake... calls. 

No Geometry (except 
in retained objects). 

i 

RiWorldBegin 

Camera projection frozen. 

Lights and attributes. 

i 

1 

1 

Current transform set to 
identity'. Pushes attributes 
and transformations. 

No Options. 

RiAttributeBegin 

i 

i 

RiAttibuteEnd 

Pushes attributes and 
transformations. 

May be nested in or around i 
other Begin-End pairs. 

. Pops attributes and trans- 
formations. Turns off, but 
does not delete, lights. 

Attributes, transforma- 
tions and geometry, 
i No Options. 

l 

RiTranstorm Begin 

RiTransformEnd 

RiWoridEnd 

j : 

i 

i Pushes transformations. Attributes, transforma- 

Mav be nested m or around! tions and geometry, 
other Begin-End pairs. i No Options. 

Pops transformations. | 

Pops attributes and 
transformations. 

Deletes enclosed lights 
and retained objects. ! 

Finish frame. 

RiFrameEnd 

Pops options, attributes & 
transformations. 

Deletes enclosed lights 
and retained objects. 

No Geometry. 

i 

RiEnd 

Shutdown 



RenderMan Program Structure 
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APPENDIX B 


Constructing Basis Matrices 
for Bicubic Surfaces 


Introduction 

The basis matrices used to specify surfaces in the RenderMan 
Interface provide a variety of useful surface types, but their 
generality is limited by the fact that the matrices themselves 
are predefined, and therefore constant. Learning to construct 
basis matrices is well worth the effort, because it provides ac- 
cess to several much more flexible classes of surfaces. This ap- 
pendix provides the information needed to construct these 
matrices and shows examples of them applied to surfaces. 

This information, and the characterization of a wide variety 
of uniform bicubic splines in terms of basis matrices, is due to 
an unpublished paper by Tom Duff [DUFF83]. His work there 
is truly insightful and powerful, adding significantly to the 
generality of the basis matrix formulation. 

Interpolating vs. approximating 

We have already seen in Chapter 6 the distinction between in- 
terpolating and approximating surfaces: interpolating splines 
like the Catmull-Rom and Hermite splines guarantee that a 
curve or surface will pass through its control points. An ap- 
proximating spline like the B-spline is influenced by its con- 
trol hull, but does not in general pass through any of the 
points. The Bezier splines represent a compromise between 
the two: they interpolate some points of the control hull, but 
not others. 
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Each type o 
spline is mos' 


spline is useful in its place: an interpolating 
likelv to be used where a surface is fit to a set of 


points, but an approximating spline is more useful for interac- 


tive design w 
importance 

Tension and 


here the smoothness of the surface is of greatest 


Dias 


Even restricting the interpretation of control points in a sur- 
face to approximation or interpolation, there is still plenty of 
freedom. A given set of control points can be interpolated in- 
to many different surfaces, for example. The classes of splines 
discussed here differ in how the}' incorporate characteristics of 
bias and tension into their resulting splines. 

Tension refers to the "gravity" of a spline, the attraction of 
the control points for the curve or surface. A very tense spline 
looks more like its control hull than an untense spline. Fig- 
ure B.l shows a spline under different tensions. 


tie 


Bias refers to 
The concept is 
B.2. More forma 
two derivatives 
curve will be fla 


symmetry of the spline near a control point, 
lest illustrated with a figure, specifically Figure 
lly, bias expresses the relative strengths of the 
on either side of a knot. A highly biased 
ter on one side of a knot than on the other. 


The spline type! discussed in this chapter vary in their atten- 
tion to tension and bias as well as their interpolating or ap- 
proximating qualities. Tension and bias are expressed in the 
basis matrix usjmg algorithms set out both mathematically 
and with C procedures. The resulting basis matrices are suit- 
able for passing to RiBasrsO to produce surfaces. The ubasis 
and vbasis matrices may be different. 

The first section presents the tensed Cardinal splines. The sec- 
ond section introduces tension into B-splines. The third sec- 
tion presents a biased interpolating spline, and the fourth dis- 
cusses basis matrix construction for the well-known Beta 
splines, a class pf approximating spline which incorporates 
both bias and tension. 

In the spirit of RenderMan in general, we minimize the theo- 
ry 7 here, emphasizing methods and results. 
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Figure B.l Tensed spline: :he higher the tension, the closer the curse lies to the 
control points 


Protocol 

The RtBasis basis matrices defined below are passed to RiBa- 
si$() just as the predefined matrices were in Chapter 6. In all 
cases, the corresponding step parameter should be 1. An 
N x M grid of control points, if used to create an unwrapped 
patch mesh, will create (N-3XM-3) patches; if wrapped, the 
grid will create NxM patches. 


Introduction 
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A Tensed Interpolating Spline 

The Cardinal splines are a generalization of Catmull-Rom 
splines, introducing a tension parameter. If f represents ten- 
sion in the range [0,1], the basis matrix for a Cardinal spline is 
given by 

-f 2-f t-2 t 

2 1 t-5 3-2 i -f 

-f 0 If 0 

0 1 I 0 0 I 

Listing B.l gived a routine that generates a Cardinal spline ba- 
sis matrix, given tension. 


/x GetCardinalBasis:; ' return, in 'm', a Cardinal spline basis 

matrix from tension parameter 'tension'. \ 

GetCardinalBasis tenlion rr. 
double tension* 

RtBasis m: 

mt0J!0; = -tension; 
m|0]p 1 = 2 - tension' 
m!0)i2j = tension - 2; 
m|0j|3] = tension 

m[l ] [0] = 2‘iension; 
mjl ] [1 j = tension - 3; 
m[l][21 = 3 * 2*t6nsion; 
m|1](3j = -tension; 

m[2] [0] *• -tension; 
m[2]p] = 0; 
m[2][2] = tension; 
ml2J13]*0; 

m [3] fO) = 0; 
m[3)I1]* 1; 
mI3][2] = 0; 
m[3)[3) = 0; 

i I 

Listing B.l Cardinal spline basis matrix 
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Figure B.3 shows the effect of varying tension from 0 to 2, al- 
though negative tension values are allowed. A Cardinal 
spline with tension = 0.5 is a Catmull-Rom spline. 

A Tensed Approximating Spline 

Like Catmull-Rom splines, the B-spline can be generalized to 
include tension. Again, if t is tension, the basis matrix for a 
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Figure B.3 Cardinal spline with tension varying from 0 (at top) to 0.5, 1 and 2 
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tensed B-spline is 



- 1 

12-91 

91-12 

1 

1 

31 

121-18 

18-151 

0 

6 

-31 

0 

31 

0 


1 

6-21 

1 

0 


The routine CetTensedBSplineBasisi ) creates such a matrix, 
given tension, which should normally lies in the range [0,1]. 


A GetTensedBSplineSasisO: produce a RenderMan basis matrix for a 8- 
spline with tension 7 

GetTensedBSpiineBasis tension, m ) 
double tension; 

RtBasis m; 

I 

double sixth = ‘*.0/6.0 
m[0|[0) = sixth* -tension); 
mjojfll = sixth m, 12 - 9*tension); 
m[0][2] = sixth* 9“:ension - 12); 
m[01I3] = sixth":e.nsion; 

m[l j[0] = sixth* 3 “tension); 
m(l){lj = sixth* ‘2*tension - 18); 
m[l ] [2 j = sixth*' ‘ 8 - 15 ‘tension); 
mil I[3) = 0; 

m [2] [01 ® sixth“'-3*tension); 
m[2](1 ] = 0; 

mf2) [2] = sixth*3“tension); 
m[2][3] = 0; 

m [3] [0] = sixth'tension; 
m [3J[1 1 = sixth‘;6-2“tension); 
m[3]|2] = sixth“tension; 
m(3|[3j = 0; 


Listing B.2 Creating a tensed B-spline basis matrix 


Figure B.4 shows a B-spline with tension varying from 0 to 2. 

If tension = 1, the basis matrix from this routine yields RiB- 
SpIineBasis. Note that tension has an unusual sense here; 


A Tensed Approximating Spline 


399 



when it is 0, the curve is maximally tense (it coincides with 
the control hull). 


A Biased, Tensed Interpolating Spline 

The last basis matrix presented here yields an interpolating 
spline with both bias b and tension t. Dubbed by Tom Duff the 
Tau spline, its basis matrix is: 

(fr-l)f 2-bt (l-b)t-2 bt 

2(l-bjt (3h-l)f-3 3-f -bt 

(b-l)t (1-2 b)t bt 0 

0 1 0 0 

L J 

CetTauBasisO in Listing B.3 produces a RenderMan basis ma- 
trix according to this formulation, taking both bias and ten- 
sion parameters. 


• / * CetTauBasisO: produce a basis matrix for an interpolating spline with 
both bias and tension * 

GetTauBasis( bias, tension, m \ 
double bias, tension: 

RtBasis m; 

( 

m[0][0) = tension * ;bias-l 
m[0)P ] = 2. - tension*bias; 
m [Oj [2 1 = tension * fl .-bias) - 2.; 
m[0)[3J = tension * bias; 

m[l ] [0] = tension m 2. “H .-bias); 
m[l)[lj = tension “ (3. “bias - 1.}- 3.; 
m(lj[2] = 3. - tension; 
m[l ][3] = -tension ’ bias; 

m [2 j [01 = tension * {bias - 1.); 
m[2]h j = tension * (1 . - 2. “bias); 
m[21(2] = tension m bias; 
m[2][3) « 0.; 

m[3)[0] «0.; 
m(3][1] = 1 
m[3][2| = 0.; 
m (3 ] [3] = 0.; 


Listing B.3 Creating a basis matrix for a Tau spline 
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The Cardinal spline seen previously is equivalent to this 
spline with bias = 0.5. Figure B.5 shows curves generated with 
a basis matrix from GetTauBasisQ. Again, tension and bias are 
not restricted to the range [0,1], but become more difficult to 
control outside. 


A Biased, Tensed Approximating Spline 

Beta-splines are an approximating spline with both bias and 
tension developed by Brian Barskv [BARSKY81]. For bias b 
and tension f, the Beta-spline basis matrix is 

- 2 53 2(t+b^-rb 2 -rb) -2{t+&+b+l) 2 

6 b 3 -3(f+2h3+2i> 2 ) 3t-6b 2 0 

-6b 3 6 ib 3 -b) 6b 0 

2 b 3 t+4b 2 +4b 2 0 


1 

t-r2t> 3 ~4b 2 -4b-2 


A Beta-spline basis matrix is produced by GetBetaSplineBa- 
sisQ, in Listing B.4. 


CetBetaSpiineBasiSi Dias, tension, m ) 
double bias, tension; 

RtBasis m; 


double bias2, bias3, d; 

bias2 = bias'bias; 
bias3 = bias*bias2; 

d = 1 /( tension - 2“bias3 + 4*bias2 + 4“bias + 2); 
m[0] [0] = -d K 2“bias3; 

m[0][1] = d w 2 m { tension + bias3 + bias2 - bias •: 
m[0][2] = -d"2“{ tension + bias2 + bias + 1 ); 
m[0J[3] = d-2; 

m[l ][0| = d*6*bias3; 

m[1 ][1 ] = -d“3 - ( tension + 2*bias3 + 2 K bias2 ); 
m [1 ] [2] = d*3*( tension + 2* bias2 ); 
mp][3] = 0; 

m[2] [0] = -d*6’bias3; 
m[2][1] = d*6*( bias3 - bias ); 
m[2|[2] = d“6“bias; 
m [2] [3) » 0; 
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mI3](0] = d 

“^biasS; 

m|3]|1]*d 

“(tension + 4*{ bias2 + bias )}; 

m[3][2] = d 


ml3)[3J = 0 

) 


Listing B.4 Great 

ng a Beta-spline basis matrix 



The previous B-spline with tension g is equivalent to a Beta 
spline with a bias of biast, = 1 and a tension of tension b = 12(1— 
tension^) /tension^. The tension of a Beta-spline varies from 0 
to infinity, whereas that of the tensed B-spline varies from 0 
to 1. Figure B.l was of a Beta spline with bias of 1 and tension 
varying between 0 at the top, 10 in the middle and 100 at the 
bottom. Figure B.2 showed a Beta spline with fixed tension of 
10 and bias, fropi top to bottom, of 0, 1, and 2. 


Further Reading 

An excellent reference on the mathematics of curve and sur- 
face specification is An Introduction to Splines tor use in Comput- 
er Graphics ana Geometric Modeling [BARTELS87]. A slightly 
more accessibly treatment is the book bv Gerald Farin 
IFAWN88). 
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APPENDIX C 

The ri.h Header File 


/* * 

** Copyright (c) 1 988 Pixar. All rights reserved. 


V • 

/" 

* RenderMan Interace Standard include File 

* Pre-ANSI taka KSR C version 

V 


/* Definitions or Abstract Types used in Rl m/ 


tvpedef short 
typedef long 
typedef float 

typedef char 

typedef RtFloat 
typedef RtFloat 
typedef RtFloat 
typedef RtFloat 
typedef RtFloat 
typedef char 

typedef char 
typedef int 
typedef double 
typedef RtVoid 


RtBooiearr 

Rtlnt; 

RtFloat; 

“RtToken 

RtColor[3j; 

RtPoint[31; 

RtMatrix(4]|4]; 

RtBasiS{4j(4j; 

RtBound(6j; 

“RtString; 

“RtPointer; 

RtVoid; 

(“RtFloatFuncK); 

("RtFunc)0; 


typedef RtPointer RtObjectHandle; 
typedef RtPointer RtLightHandle; 
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/* Extern Declarations for Predefined RJ Data Structures V 


^define Ri.FALSE 
^define Rl^TRUE 
^define RiJNFINITY 
^define RLEPSILC'N 
^define RLNULL 


0 

(! RI.FALSE) 
1 .Oe36 
1.0e-10 
((RtToken)O) 


extern RtToken 
extern RtToken 
extern RtToken 
extern RtToken 
extern RtToken 
extern RtToken 
extern RtToken 


RI.FRAMEBUFFER, R!_FILE; 

R1JRCB, RI.RGBA, RI.RCBZ, RLRGBaZ. Rl.A RI.Z, RLAZ; 
ftl.MERGE, RI.ORIGIN; 

^.PERSPECTIVE, RLORTHOGRAPHIC: 
fil.HIDDEN, RI.PAINT; 

Fil.CONSTANT, RLSMOOTH; 

Fii.FLATNESS, RLFOV; 


extern RtToken 
extern RtToken 


extern RtToken 
extern RtToken 

extern RtToken 
extern RtToken 


F,1 AMB1ENTUGHT, R! POINTLIGHT, 
FJJDISTANTLIGHT, R1.SPOTLIGHT; 

F G INTENSITY, Rl.UGHTCOLOR, RI.FROM, RI.TO, 
R LCONEANGLE. RLCONEDELTAANGLE. 
RLBEAMD1STRIBUTION; 

Ri_MATTE.. RLMETAL, RLPLASTIC; 

RI.KA, RI_KD, Ri.KS, Rl.ROU GHNESS. 
RLSPECULARCOLOR; 


.DEPTHCUE, RLFOG; 

R|_M IN DISTANCE. RLMAXDISTANCE, 
.BACKGROUND, RLD1STANCE; 



extern RtToken 

extern RtToken 
extern RtToken 

extern RtToken 
extern RtToken 

extern RtToken 

extern RtToken 


R .RASTER, R! SCREEN, RI CAMERA, R WORLD, 
R .OBJECT; 

R .INSIDE, RLOUT5IDE, RLLH, Rl.RH; 

RlP, RI PZ, Ri PW, RI N, RI NP, RI CS, Rl OS, 
Rifs, RLT, Ri.ST; 

RILBILINEAR, Ri.BICUBIC; 

riLprimitive, rIjNTERSECTION, R1.UNION, 

Rij_DIFFERENCE; 

Ri WRAP, RL NO WRAP, RI.PERIODlC, Rl.CLAMP, 
RLBLACK; 

RIJGNORE, RI.PRINT, RI.ABORT, Rt.HANDLER; 



a 


extern RtBasis 


RiBezierBasis, RiBSplineBasis, RiCatmuliRomBasis, 
RiHermiteBasis, RiPowerBasis; 


^define RI.BEZIERSTEP 
^define RLBSPLINEfiTEP 
^define RI.CAT M U LLROMSTE P 
^define RLHERMlTflSTEP 
^define Ri.POWERSTEP 


((Rtlnt)3) 

((Rtlnt)l) 

((Rtlnt)l) 

(CRtlnt)2) 

((Rtlnt)4) 


extern Rtint 


Ri 


LastError; 
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/* Declarations of All of the RenderMan Interface Subroutines 7 


extern RtToken 

RiDeciareO; 

extern RtVoid 

RiBeginO, RiEndQ, 

RiFrameBeginQ, RiFrameEndO, 

RiWorldBeginO, RiWorldEndO; 

extern RtVoid 

RiFormatO, RiFrameAspectRatioO, RiScreenWindowQ, 
RiCropWindowQ, RiProjectionO, RiProjectionVO, 
RiClippingO, RiDepthOfFieldO, RiShutter ; 

extern RtVoid 

RiPixelVarianceQ, RiPixelSamplesO, RiPixelFilterj, 
RiExposureO, RiimagerQ, RilmagerV(j, 

RiQuantizeu, RiDisplayO, RiDisplayV':; 

extern RtFloat 

RiCaussianFilterO, RiBoxFilterO, 

RiTriangleFiltert), RiCatmullRomFilteri), RiSincFilterO; 

extern RtVoid 

RiHider}, RiHiderVO, 

RiCoiorSamplest), RiRelativeDetailO, 

RiOptiont;, RiOptionVO; 

extern RtVoid 

RiAttributeBeginO, RiAttributeEndO, 

RiColor RiOpacityO, RiTextureCoordinates: ; 


extern RtLightHandie RiLightSourceO, RiLightSourceV'\ 

RiAreaLightSourceO, RiAreaLightSourceV 


extern RtVoid 

RillluminateO. 

Ri Surface:;, RiSuriaceVG, 

RiAtmosphereO, RiAtmosphereV(!, 

Rilnteriorf), RiinteriorVQ, RiExteriori/, RiExteriorVQ, 
RiShadingRateO, RiShadinglnterpoiatiom,. RiMatteij; 

extern RtVoid 

RiBoundt,, RiDetailO, RiDetailRange 1 ), 
RiGeometricApproximationO, 

RiOrientationO, RiReverseOrientationO, RiSidesO; 

extern RtVoid 

RildentityO, RiTranstormO, RiConcatTransformO, 
RiPerspectiveO, 

RiTransiateO, RiRotatet). RiScaieO, RiSkew;), 
RiDeformationO, RiDeformationV(), 

extern RtPoint 
extern RtVoid 

RiDisplacementO, RiDisplacementVQ, 
RiCoordinateSystemQ; 

*RiT ransformPointsO; 

RiTransform Begin() , RiTransformEndO; 

extern RtVoid 

RiAttributeO. RiAttributeVQ; 

extern RtVoid 

RiPolygonO, RiPolvgonVQ, 
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extern RtVoid 


RiGeneralPolygonG, RiGeneralPolygonVO, 
RiPoirJtsPolygonsQ, RiPointsPolygonsVO, 
RiPoifjtsGeneralPolygonsO, RiPointsGeneralPolygonsVO, 
RiBasisO, 

RiPatchO, RiPatchVQ, RiPatchMeshQ, RiPatchMeshV{), 
RiNuPatchO, RiNuPatchVO, RiTrimCurveO; 

RiSphereQ, RiSphereVQ, RiConeO, RiConeV( ; . 
RiCvlhderQ, RiCylinderV(), 

RiHvpjerboloidO, RiHyperboloidVO, 

RiParaboloid;,, RiParaboloidVO, RiDiskQ, RiDiskVC, 
RiTorisO RiToriisVO, 

RiPro£edurai(;, RiGeometryO, RiGeometryW 


extern RtVoid RiSolic) 
extern RtObjectHandie 
extern RtVoid RiObj^ 
RiMotii 


extern RtVoid 


BeginO, RiSoiidEndO ; 

RiObjectBeginO; 
ctEnd;;, RiObjectlnstanceO, 
onBeginO, RiMotionBeginVQ, RiMotionEnd! 


extern RtVoid 
extern RtVoid 


RiMak e?T extureO, RiMakeT extureVQ, 

RiMak ?Bump{), RiMakeBumpVQ, 

RiMakfeLatLongEnvironmentO. 

RiMakeLatLongEnvironmentVO, 

RiMaki»CubeFaceEnvironment( ; , 

RiMakeCubeFaceEnvironmentVO. 

RiVtakeShadowf;, RiMakeShadowVO; 

RiError Handier- ■; 

RiErrorflgnorej, RiErrorPrintb, RiErrorAbort 




\ 
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APPENDIX D 


List of RenderMan Functions 


RenderMan Interface Routines 

In the following declarations, parameteriist represents an op- 
tional list of parameters to the routine arranged in token-val- 
ue pairs and terminated with the special token RI_\'ULL. 
These are discussed on page 39. 


RtLightHandle RiAreaLightSource; name parameteriist 
char 'name; 

225 

RiAtmospherei name, oarameterlist 
char 'name; 

235 

Ri Attribute! name, oarameterlist ) 
char “name; 

46 

RiAttributeBegin 

50 

RiAttributeEndi 

50 

RiBasis( ubasis, ustec, vbasis. vstep ) 

RtBasis ubasis. voasis; 

Rtlnt ustep, vsteo; 
typedef RtFloat RtBasis (4 1 [4 j ; 

RtBasis RiHermiteBasis, 

RiCatmuIIRomBasis, 

RiBezierBasis, 

RiBSpiineBasis; 

93 

RiBegin( name ) 

RtToken name; 

48 

RiBound( bound > 

RtBound bound; 

125 
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RiClippingf near, far ) 

RtFloa! near, far; 

RiColorl Cs ) 

RtColor Cs; 

RiColorSamplesi N, nRGB, RGBn ) 

Rtlnt N; 

Rt Float nRCB|MJi 3 ], fcG 5 n! 3 ][N]; 

RiConcatTransform: transform } 

RtMatrix transform; 

RiCone( height, radius, thetamax, parameter! ist ) 
RtFloat height; 

RtFioat radius; 

RtFloat thetamax; 


RiCoordinateSystem: ipace ) 

RtToken space; 

RiCropWindow( left, right, top, bottom ) 

RtFloat left, right, top, bottom; 

RrCylinden radius, zmin zmax, thetamax, parameterlist ) 
RtFioat radius- 
RtFloat zmin, zmax; 

RtFloat thetamax; 

RtToken RiDeclare: nams, declaration ) 
char "name; 
char "declaration; 

RiDeformation{ name, parameterlist ) 
char "name; 


RiDeptbOf Field: fstop, fpca) length, focaldistance ) 
RtFloat fstop, focaliength, focaldistance; 

RiDetail( bound ) 

RtBound bound; 

RiDetailRange( offlow, ohlow, onhigh, offhigh ) 
RtFloat offlow, onlow, jonhigh, offhigh; 

RiDi$k( height, radius, thetamax, parameterlist) 
RtFloat height; 

RtFloat radius; 

RtFioat thetamax; 


RiDisplacementt name, 
char *name; 


parameterlist ) 


145 

213 

43 

116 

62 

123 

162 

63 

242 

117 

185 

195 

197 

62 

260 
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RiDispIay( name, type, mode, parameterlist ) 
char ‘name; 

RtToken type, mode; 

RiEndo 4 8 

RiErrorHandier( handier ) 38 

RtFunc handier; 

RiExpOSUre( gain, gamma ) 1 80 

RtFloat gain, gamma; 

RiExteriorf name, parameterlist ) 235 

cnar ‘name; 

RiFormat( xresolution, vresolution, pixeiaspectratio 156 

Rtint xresolution, vresolution; 

RtFloat pixeiaspectratio; 

RiFrameAspectRatio, rrameratio ) 159 

RtFloat rrameratio; 

RiFrameBegirv numoer ) 51 

Rtint number ; 

RiFrameEndo 

RiGeneraiPolygont nioops, nverts, parameteriist ' ”8 

Rtint nioops; 

Rtint nverts []; 

RiGeometricApproximationi type, value } 1 22 

RtToken type; 

RtFloat value; 

RiHider( type, parameteriist ) 54 

RtToken type; 

RiHyperboioid{ pointl , point2, thetamax, parameterlist • 63 

RtPoint pointl , point2; 

RtFioat thetamax; 

Rildentityt ) 1 1 7 

Rillluminatet light, onorf ) 21 7 

RtLightHandle light; 

RtBoolean onoff; 

Rilmager( name, parameterlist) "I 81 

char ‘name; 

Rilnterior( name, parameterlist) 235 

char *name; 

RenderMan Interface Routines 4 ^ 1 


RtLightHandle RiLigbtSource name, para mete Hist) 
char ‘name; 

RiMakeBumpt imagtfiie, bumpfiie, swrap. twrap, filterfunc, swidth, 
twidth, parameters: ) 
char *imagefile, ‘bumpfiie; 

RtFioatFunc filterfunc; 

Rf Token swrap. twrap; 

RtFloat swidth, twidth: 

RiMakeCubeFaceErjvironment px,nx, py,ny, pz,nz, retifiie fov, 
fiherfunc, swidth ( twidth parameter! ist } 
char *px, *nx, ‘py, ‘ny, *p2. ‘nz* 
char ‘refifiie; 

RtFloat fo\ r ; 

RtFunc filterfunc, 

RtFloat swidth, twitith; 

RiMakeLatLongEnvironment imagefiie, reflfile, filterfunc, swidth, 

Twidth, parameter! lit ) 
char ‘imagefiie, ‘relfile; 

RtFioatFunc filtenunc; 

RtFloat swidth, twicth; 


216 


259 


263 


RiMakeShadow picfi 
char ‘picfile* 
char ‘sha dowtile; 


e, shadow? ile, parameteriist ) 


RiVlakeTexture imagefiie, texturefile, swrap, twrap, filterfunc, 
swidth, rwidth, parameter! is: ) 
char ‘imagefiie, ‘texturefile; 

RtToken swrap, twrap; 

RtFioatFunc fiiterfun 
RtFloat swidtn, twidth; 

RiMatte( ) 

RiMotionBegin( N, time!, .... timeN ) 

Rtint N 1 ; 

RtFloat time!, timeN; 

RiMotionEnd( ) 

RiNuPatch(nu, uorder, uknot, umin, umax, nv, vorder, vknot, 
vmin, vmax, paramefe/7/sf ) 

Rtint nu, nv; * 

Rtint uorder, vorder; 


263 


269 


256 


216 

189 

189 

104 


RtFloat uknot[], vknotp; 

RtFloat umin, umax, vjmin, vmax; 

RtObjectHandle RiObjectBegin{ ) 


133 
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RiObjectEnd( ) 133 

RiObjectlnstance( handle ) 1 34 

RtObjectHandie handle; 

RiOpacitv( Os ) 213 

RtCoior Os ; 

RiOptionf name, parameterlist ) 46 

char ‘name; 

RiOrientation( orientation > 121 

RtToken orientation; 

RiParaboloidi rmax, zmin, zmax, thetamax, paramete r list 66 

RtFloat rmax; 

RtFloat zmin, zmax; 

RtFloat thetamax; 

RiPatch( type, parameter! is: ) 87 

RtToken type; 

RiPatchMeshi type, nu uwrap, nv, vwrap. parameter! 1st 98 

RtToken type, uwrap, vwrap; 

Rtlnt nu, nv; 

RiPerspectivei fov ] 1 -1 

RtFloat fov; 

RiPixelFilter function, xwidth, ywidth ) 1*6 

RtFloatFunc function; 

RtFloat xwidth, ywidth: 

RiPixe!Samples{ xsamples, ysamples ) 176 

RtFloat xsamples, vsampies; 

RiPixelVariancet variance 1 1 *9 

RtFloat variance; 

RiPointsCeneraIPoIygons( npolys, nloops, nveis, verts. 

parameterlist ) 82 

Rtlnt npolys; 

Rtlnt nloopsf]; 

Rtlnt nverts[]; 

Rtlnt verts []; 

RiPointsPolygons( npoivs, n verts, verts, parameterlist f 79 

Rtlnt npolys, nvertsfl; 

Rtlnt verts []; 

RiPolygon( nvertices, parameterlist ) 70 

Rtlnt nvertices; 
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RiProcedliraI( data, bot-jnd, refineproc, freeproc ) 
RtPointer data; 

RtBound bound; 

RtFunc refineproc, freeproc; 

RiPrO)€Ction( name, panameterlisi ) 
char ‘name; 

RiQuantize; type, one, min, max, ditheramplitude 
RtToken type; 

Rtlnt one, min ; max; 

RtFIoat ditheramplituce; 

RiRelativeDetail reiativjedetai! 

RtFioat reiativedetaii, 

RiReverseOrientation 

RiRotate. angle, dx, d>, c, 

RtFioat angle, dx, 6 \ , c 2 ; 

RiScreenWindow; left, r ght. bottom, top ) 

RtFioat left, right, bottcm, top; 

RiShadinglnterpolation tvpe > 

RtToken type; 

RiShadingRate^ si2e ) 

RtFioat size; 

RiShutter* opentime, dosatime 
RtFioat opentime, close lime; 

RiSides nsides } 

Rtlnt nsides; 

RiSolidBeginitype } 

RtToken type; 

RiSolidEnd ) 

RiSphere: radius, zmin, zmix, thetamax, parameterlist 
RtFioat radius; 

RtFioat zmin, zmax; 

RtFioat thetamax; 

RiSurface( name, parameterlist ) 
char *name; 

RiTextureCoordinates( si , tl , s2, \l, s3, t3, s4, t4 ) 
RtFioat si, tl ; 

RtFioat s2, t2; 

RtFioat s3, t3; 

RtFioat s4, t 4; 


149 

1 S3 

196 

122 

112 

150 

215 

21 ^ 

190 

119 

126 

126 

62 

231 

251 
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RiTorus( majorrad, minorrad, phimin, phimax, thetamax, parameterhs: ) 66 

RtFloat majorrad, minorrad; 

RtFloat phimin, phimax; 

RtFloat thetamax; 

RiT ransform( transform ) 

RtMatrix transform; 

RtPoint “RiTransformPoints( fromspace, tospace, npoints, points ) 123 

RtToken fromspace, tospace; 

Rtint npoints; 

RtPoint points []; 

RiTranslatei dx, ri\. dz 
RtFloat dx, dv, cz; 

RiTrimCurvei nioops, ncurves, order, knot, min, max. n. u. v w ) 

Rtint nioops, ncurvest], order[], n[); 

RtFloat knot[], minf], max[], u[!, v[], w[}> 

RiWorldBeginn 
RiWorldEndo 

RenderMan Shading Language Routines 

The following list of routines in the RenderMan Shading Lan- 
guage does not include the math functions listed in Taoie 15.1 
on page 312. 

In a few of the following declarations, textcoords represents 
an optional list of texture coordinates in 2 texture map as dis- 
cussed on page 320. 

A parameterlist argument represents an opdonal list of param- 
eters arranged token-value pairs. These are not terminated 
with an RIJMULL token. 

color ambiento 315 

float area( P } 

point P; 327 

point bump{name[channel], norm, dPds, dPdt, textcoords. parametenist) 

322 

string name; 

float channel; 

point norm, dPds, dPdt; 


249 

48 

48 
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point calculatenormal D ) 330 

point P; 

float comp; c, index 330 

color c; 
float index; 

float depth( P } 329 

point P; 

color diffuse(norm - 316 


point norm; 

float distance' pi. p2 1 
point pi , p2; 


Deriv; num denorr 313 

Du( expr ) 313 

Dv(expr) 313 

color environment namelchannel]., direction, parameterlist ) 323 


string name 
float channel: 
point direction- 

point faceforward v R 328 

point V, R; 

fresnel; l N\ eta, Kr K\[. R, t \ j 329 

point I, N; 
float eta, Kr, Kt; 
point R, T ; 

float lengths V ) 326 

point V; 

color mix( colorO, colorl . a ) 331 

color colorO, colorl ; 
float a; 

noise(val) 314 

float vai; 

noise(u, v) 314 

float u, v; 

noise(pt) 314 

point pt; 

color phong(norm, eve, size) 316 

point norm, eye; 
float size; 
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printf( format, va!1,...,valN ) 
string format; 

point refract( I, N, eta ) 
point 1, N; 
float eta; 

setcompi c, index, value > 
color c; 

float index, value; 

setxcomp( P, val ) 
point P; 
float val; 

setvcompt P, val ) 
point P; 
float val; 

set2Comp( P, val ) 
point P; 
float val; 

float shadow! name! cnanne!], position, parameterlist 
string name; 
float channel; 
point position; 

color specular! norm, eve, roughness } 
point norm, eye; 
float roughness; 

spline! value, ft , r'2...fn, fnl t 

color trace! location, direction ) 
point location, direction; 

color texture! nameichannel], textcoords, parameterlist 1 
string name; 
float channel; 

float texture! namefchannel], textcoords , parameterlist J 

string name; 
float channel; 

point transform! [fromspace, jtospace, P } 
string fromspace, tospace; 
point P; 

float xcomp! P ) 
point P; 


332 

328 


330 


326 


326 


326 


311 
3 1 9 


2 no 


329 


326 
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float ycomp( P ) 
point P; 

float zcomp,' P 
point P; 


326 

326 
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Glossary of Technical Terms 


Terms in SMALL CAPS are defined elsewhere in the Glossary. 

The page numbers in parentheses indicate where the term is 

denned or first used. 

AGGREGATE OBJECT. An OBJECT composed of many primitives. 
(Contrast to a PRIMITIVE OBJECT, which consists of a single 
primitive). (107) 

ALIASING. A reduction in image quality caused by represent- 
ing an image as an array of discrete pixel values. Details 
that are too small to be resolved can cause large, inappro- 
priate fluctuations in pixel values unless anti-aliasing steps 
are taken. (10, 174) 

ALPHA. A common name for opacity information calculated 
and stored for each pixel in a FRAME. (156, 174) 

ALTERNATIVE REPRESENTATIONS. A set of different models for 
the same object that may be chosen or combined depend- 
ing on its LEVEL OF DETAIL in the image. (196) 

AMBIENT LIGHT SOURCE. A light source that distributes light 
uniformly in all directions from no specified location. All 
objects are illuminated equally regardless of their location 
and orientation. (215) 

AMBIENT REFLECTION. The surface reflection of AMBIENT LIGHT 
SOURCES. (229) 

ANAMORPHIC IMAGE. An image that has been intentionally 
distorted in such a way that it only looks right when 
viewed with a certain device, or from a certain viewpoint. 
(161) 



ANIMATION. A sequence of images that, when shown in rapid 
succession, produces the illusion of a moving image. (33) 

APERTURE. The size of an opening used to admit light into a 
VIEWING DEVICE. The aperture, as well as the FOCAL 
LENGTH of the lens affect the DEPTH OF FIELD characteristics 
of the viewing device. (5, 8) 

APPROXIMATING SPLINE. A spline that produces a smooth 
curve from its CONTROL POLNTS without necessarily pass- 
ing through any of them. (90) 

APPROXIMATION (OF SURFACE PRIMITIVES). See GEOMETRIC AP- 
PROXIMATION. 

.AREA LIGHT SOURCE. A light source whose light emanates 
from a finite surface area as opposed to a single point. The 
shape of the area light source is specified much like an OB- 
JECT; in terms of surface primitives. (224) 

ATMOSPHERE. Air, dust, gasses, fog, etc. surrounding a surface 
that can affect the properties of light passing toward the 
viewer. (2) 

ATMOSPHERIC EFFECTS. Effects such as smoke or fog simulat- 
ing the influence of ATMOSPHERE on light reflected from 
an object. (3! 

ATTRIBUTES. Part of the GRAPHICS ENVIRONMENT concerned 
with characteristics of individual objects and surfaces. Ex- 
amples would be object color, and the CURRENT TRANSFOR- 
MATION in effect when an object is created. (44) 

ATTRIBUTE BLOCK. A sequence of RenderMan routine calls 
bracketed by RiAttributeBeginQ and RiAttributeEndQ. AT- 
TRIBUTES declared within the block affect only those ob- 
jects created after the declaration but before the end of the 
block. At the end of the block, all attributes' settings return 
to those in effect at the start of the block. Attribute blocks 
can be nested. (47) 

B-SPLINE. A particularly smooth class of APPROXIMATING 
SPLINE. See also illustration on page 91. (91) 

B-SPLINE PATCH. A type of BICUBIC PATCH formed using B- 
SPUNE curves. (90)’ 
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BASIS matrix. A matrix that determines how a GEOMETRY MA- 
TRIX of CONTROL POINTS are to be interpreted when gener- 
ating a BICUBIC PATCH. (92) 

BEZIER PATCH. A type of BICUBIC PATCH formed using BEZIER 
SPLINE curves. (90) 

BEZIER SPLINES, a class of cubic SPLINE whose first and last 
CONTROL POINTS are endpoints of the spline. The first two 
control points determine a tangent vector at the first end- 
point. The last two control points determine the tangent 
vector at the second endpoint. (90) 

BICUBIC PATCH. A four-edged PRIMITIVE SURFACE specified by 
cubic SPLINES. It is described using a ser of sixteen CONTROL 
POINTS arranged in a 4 x 4 GEOMETRY MATRIX. (87) 

BlLLNEAR PATCH. A quadrilateral with straight edges formed 
by four vertices (not necessarily co-planar) in three-dimen- 
sional space. The position of any point on the bilinear 
patch is determined using bilinear INTERPOLATION be- 
tween the vertices. (86) 

BLOCK. A sequence of RenderMan routine calls bracketed by 
special Ri...Begin() and Ri...End() routines. Blocks are used 
to denote MODES of the RenderMan Interface and to save 
and restore elements of the GRAPHICS ENVIRONMENT. (47) 

BOUNDARY. The outer extent of a polygon or other primitive 
determined by the VERTICES of the polygon and the EDGES 
that connect them; also, in CONSTRUCTIVE SOLID GEOME- 
TRY (CSG), the surfaces lying between the inside and out- 
side of a solid object. (69) 

BOUNDARY REPRESENTATION. The description of a SOLID by- 
specifying the set of adjoining SURFACES enclosing it. (126) 

BOUNDING box. The rectilinear box that barely contains a set 
of geometric objects It is specified in the current coordi- 
nate system bv giving its minima and maxima in x, y, and 
z. (124, 195) 

BUMP map. An image used to control local changes in the sur- 
face ORIENTATION when shading a surface. This can pro- 
vide subtle "bumpiness" effects on an otherwise flat sur- 
face. (257, 258, 320) 
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CALL-BY-VALUE. A method of passing parameters to a proce- 
dure that guarantees that the function cannot alter any of 
the variables passed to it as arguments. Specifically, the val- 
ue of the variablje is passed, and any changes affect only a 
ccrpv of the variable, not the variable itself. (24) 

CAMERA SPACE, a COORDINATE SYSTEM with its origin at the 
camera VIEWPOINT and positive r axis pointed along the 
direction of view. 


(52, 123) 


Capabilities (of a 

sodated with a 
control. (44) 


TENDERER). Features and characteristics a$- 
particular Tenderer, and not subject to user 


Catmull-rom patc 
mulL-Rom SPUNKS. (90) 


■i. A BICUBIC PATCH formed using CAT- 


CaTMULL-ROM SPLINE. A class of cubic SPLLNE that INTERPO- 
LATES all its CO.NTROL POLNTS but its two end points. At 
each interior point, the surrounding control points are 
used to control the spline's tangent. (91) 

CHANNEL, a single component of a PIXEL. Red, green, blue 
and ALPHA are all examples of components. (320) 

CHILDREN. For a given element in a HIERARCHICAL MODEL, 
those elements in the next level down that are associated 
with it. For example, a "foot" object might include five 
"toes" as children. (109) 

CLIPPING PLANE. A plane in WORLD SPACE parallel to the IM- 
AGE PLANE, used to delimit the parts of a scene to be ren- 
dered. Only the objects in the region between near and far 
clipping planes will t>e rendered. (145) 

CLOSED OBJECT. An OBJECT whose surfaces can be seen only 
from one side (the "outside" of the object), when it is col- 
ored opaque. (118) 

COMPOSITE SOLID. In CONSTRUCTIVE SOLID GEOMETRY, a SOLID 
formed from PRIMITIVE SOLIDS and other composite sol- 
ids. (126) 

CONCAVE POLYGON, a POLYGON with the property that a line 
can be found that passes through more that two EDGES. 
Equivalently, the sum of its interior angles is greater than 
360 degrees. See aZsq Figure 5.2. (69) 
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CONE, a QUADRIC SURFACE created by sweeping a line seg- 
ment with one end point on the axis of rotation. (60) 

CONSTRUCTIVE SOLID GEOMETRY (CSG). A method of OBJECT 
DESCRIPTION in which objects can be used to modify the 
shape of other objects. For example, a cylinder can be sub- 
tracted from a sphere to describe a finger hole of a bowling 
ball. (110,125) 

CONTROL HULL. See GEOMETRY MATRIX and Figure 6.2. (87) 

CONTROL POINTS. The set of points used to specify the geome- 
try of a SPLINE or PATCH. Cubic splines require four control 
points. BILINEAR patches require four control points (the 
vertices) and BICUBIC PATCHES sixteen. (87) 

CONVEX POLYGON. A POLYGON whose interior angles (on the 
inside of the polygon) sum to 360 degrees. Equivalently, 
there is no line that passes through more than two edges 
of a convex polygon. See also Figicre 5.1. (.69) 

COORDINATE SYSTEM, a set of orthogonal axes that meet at an 
origin. A coordinate system provides a mapping .between 
points in space and points on the axes. The location of any 
point can be specified by its coordinates relative to the ori- 
gin.' (22, 111) 

CROP window, a subwindow of the FRAME specified by Ri- 
CropWindowO. Pixels outside the crop window will not be 
RENDERED. (162) 

CURRENT INSTANCE (OF A SHADER). A SHADER and the parame- 
ters currently in effect for it that are part of the GRAPHICS 
ENVIRONMENT and attached to anv object as it is declared. 
( 212 ) 

CURRENT LEVEL OF DETAIL. The LEVEL OF DETAIL set bv the last 
call to RiDetaiiO (subject to restorals of the GRAPHICS ENVI- 
RONMENT). (195) 

CURRENT TRANSFORMATION. A transformation incorporating 
the sequence of global TRANSFORMATIONS invoked so far. 
Part of the GRAPHICS ENVIRONMENT. (44, 53, 110) 

CYLLNDER. A QUADRIC SURFACE created by sweeping a line seg- 
ment that is parallel to the axis of rotation. (60) 

DECAL. See TEXTURE MAP. (240) 
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DEPTH CUE. a \isual cue providing information about the rel- 
ative distance to the camera of different surfaces, (e.g., 
DEPTH OF FIELD effects) (4) 


DEPTH OF FIELD, 


appear sharply focused. (5, 8, 185) 

FAUL' 

(23) 


DEFAULT values. Values in effect unless changed by the user. 


am 


Deformation 
object or s< 
the COORDD- 
TRANSFORM. V 


DIFFUSE REFlEC 
TERLNG ligh 


reflection is 
to the light 

Directional l 


. The range of depth over which some objects 


A nonlinear TRANSFORMATION applied to an 
ies of objects effectively bending or warping 
;.ATE SYSTEM. It is concatenated to the CURRENT 
.TION. (278) 


That set containing all the elements of one 


DIFFERENCE (SE 

set that are lio: contained in another. (126) 


TION. The reflection caused by a surface SCAT- 
equallv in all directions. The intensity of the 
proportional to the area the surface presents 
urce. (3, 230) 

HT SOURCE. See DISTANT LIGHT SOURCE. (305) 


so- 


jg: 


DISPLACEMENT SHADER. A SHADER that specifies local changes 
in position oi points on a surface. (118, 259, 279) 

DISTANT LIGHT SOURCE, a light source that is created as if it 
were an infinite distance from the scene and so casts light 
in only one direction. The ORIENTATION of a surface is rel- 
evant to how it reflects the light, but not its distance (from 
the light source) or location. (221) 

DISPLAY (MONITOR). A cathode-rav tube monitor used to dis- 
play a computer generated image. (9) 

DITHERING. A technique used to reduce the effects of QUANTI- 
ZATION by adding a "random" amount of noise to pixel 
values before quantization. (184) 

EDGE. Where two SURFACE PRIMITIVES meet, or where a sur- 
face primitive ends. In the RenderMan Interface, edges 
are implicit in the vertices of the polygon. (69) 

ENVIRONMENT. The visual surroundings of an object, often 
seen in reflections from the surface of the object. (6) 

ENVIRONMENT map. An image depicting a scene from a view- 
point inside one of its objects. Its most common use is as a 
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REFLECTION MAP simulating the effect of a surface reflect- 
ing the objects around it. (230, 257, 261) 

Evaluation window, a set of four adjacent control 
POINTS used when traversing a series of cubic SPLINES. In 
the RenderMan Interface a set of 16 adjacent points used 
to create a single PATCH while generating a PATCH MESH. 
(95) 

EXPOSURE. A step in the pixel production process of RENDER- 
ING in which pixel values are passed through a function 
that compensates for the non-linear response to light of 
DISPLAY MONITORS and the human visual system. (179) 

EXTERIOR VOLUME SHADER. A SHADER that calculates the effect 
on light passing through the space around an object. (278) 

F-STOP. The ratio of FOCAL LENGTH to APERTURE. The f-stop of 
a camera determines its DEPTH OF FIELD. (185) 

FALSE CONTOURS. Regions of abrupt changes in pixel values 
in an image caused by problems with QUANTIZATION. See 
also Figure 9.2. (10) 

F.ALLOFF (WITH ANGLE F) In a SPOTLIGHT, the decay in intensity 
of light with the angle from the center of its beam. See also 
Figure 11.5. (222) 

FIELD OF VIEW. The angle at the viewpoint specifying the part 
of the scene viewable by the VIRTUAL CAMERA in the direc- 
tion it points. See also, equation and figure on page 14S. (4, 
141, 147, 148) 

FILTER FUNCTION, a function for weighting the contribution 
to an output PIXEL value of different parts of the scene as 
projected near the pixel. When SUPERSAMPLING, the filter 
function determines the contribution of each SAMPLE in 
or near a pixel to the overall pixel value. Specifically it 
gives the relative sample weights as a function of x and y 
displacement from the center of the pixel. See also Figure 
9.2. (176) 

FILTERING. Calculating a single pixel value from multiple 
SAMPLES taken in the neighborhood of a pixel. (9, 174, 176) 

FLAT SHADING, a form of SHADING in which each surface has 
the same color at all points, causing an abrupt color 
change at the edge between one surface and another. (71) 
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Focal DISTANCE The distance in front of a camera at which 
objects appee r most in focus. (185) 

FOCAL LENGTH. The distance between the center of a lens and 
its FOCAL POINT. (146, 185) 

FOCAL POINT. The point at which rays of light converge after 
passing through a lens. In the RenderMan Interface, the 
focal point ijs also the location of the VIRTUAL CAMERA. 
(146) 

FRAME, a rectangle of pixels representing a SCREEN WLNDOW. 
(137, 160) 

FRAME BLOCK, a BLOCK of code in a RenderMan program 


bracketed bv 


RiFrameBeginO and RiFrameEndO statements, 


used to generate successive frames of an .ANIMATION. 
RiFrameBeginO) and RiFrameEndO save and restore OP- 
TIONS so that thev mav bv changed between frames. (50) 

FRAME ASPECT RjTJO. The ratio of width to height of a FRAME, 
equal to the IMAGE ASPECT RATIO unless set explicitly by a 
call to RiFrameAspectRatioO. (159) 


Geometric appi: 

aered PRIMITIV 
describe a seen 


sur: 


Geometric norj 

point on a 
that point, (a 
can be set exj 
ING calculation 


OXIMATION. Substituting more easily ren- 
TE 5URFACE tvpes for the primitives used to 
e. (171) 


Hal (VECTOR). The SURFACE NORMAL at a 
face as defined by the surface geometry’ at 
opposed to the SHADING NORMAL, which 
plicitlv bv the user for the purposes of SHAD- 
s). (226, 293) 


GEOMETRIC TRANS: 


figuration of 
(change in lodi 
individual obj 


FORMATION. A change in the geometric con- 
scene such as ROTATION or TRANSLATION 
ation). A transformation can be applied to 
acts, or globally to the entire scene. (21) 


GEOMETRY MATRIX, a 4x 4 matrix of CONTROL POINTS describ- 
ing the geometry of a BICUBIC PATCH. (87) 

GLOBAL VARIABLE. In the RenderMan Shading Language, a 
variable whose value is set automatically when a SHADER 
is called. In thijS book, global variables are indicated by un- 
derlining the variable name (as in N or C/).( 284) 
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GOURAUD SHADING, a SHADING technique in which the sur- 
face shade is calculated at surface vertices, and interpolat- 
ed for points in the interior. (214) 

GRANULARITY. The density with which a viewing surface is di- 
vided into physical sensors (such as pixels in an image, 
photoreceptors in the eye, or the grains of emulsion in 
film). (4) 

Graphics ENVIRONMENT. The content of variables and values 
maintained by the interface, including image parameters, 
the CURRENT TRANSFORMATION, color, surface appearance 
specification, light sources, etc. Any object added to the 
scene adopts any relevant part of the graphics environ- 
ment in effect when it was created. (23, 44) 

Graphics state. See Graphics environment. (44) 

HEIGHT FIELD. A convenient way to specify a simple PATCH or 
MESH by giving onlv the height of each point above a 
plane (with the x and y coordinates implicit). (246) 

HERMITE PATCH. A BICUBIC PATCH defined bv HERMITE 
SPLINES. (90) 

HERMITE SPLINE. A cubic SPLINE that interpolates its first and 
third CONTROL POLNTS, using the other two to specify the 
spline's tangent at the end points. (91) 

HIDDEN SURFACE ELIMINATION, a step in the RENDERING pro- 
cess that determines what parts of the scene cannot be 
seen by the viewer so they can be disregarded when com- 
puting the image. (6) 

HlDER. The process used during RENDERING for HIDDEN SUR- 
FACE ELIMINATION. (54) 

Hierarchical MODEL. An organizational model useful for 
OBJECT DESCRIPTION that divides a system into levels of ab- 
straction. (108) 

HIGHLIGHT. The effect of mirrorlike SPECULAR REFLECTIONS. 
(226) 

HOLD-OUT MATTE. An image specifying regions to be cut out of 
another image. The resulting "holes' are rendered black 
and transparent and can be used for merging with other 
images. (216) 
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HOMOGENEOUS COORDINATES. A formulation of three-dimen- 
sional points as a vector of four scalar values. (88) 

HYPERBOLOID, a QUADRIC SURFACE created by sweeping an ar- 
bitrary line segment about an axis of rotation. (60) 

IMAGE, a two-dimensional PROJECTION of a three-dimension- 
al scene as represented in an array of PIXELS. (4). In formal 
RenderMan terminology, the actual set of pixels (either in 
a frame buffer or in a file) designated by RiDisplavO to con- 
tain the results of RENDERING. (159) 

IMAGE ASPECT ratio. The ratio of width to the height of a dis- 
played image, a function of the PIXEL .ASPECT RATIO and the 
RESOLUTION of the display. (157) 

LM.AGE plane. The two dimensional plane upon which a scene 
is projected. The SCREEN WINDOW is a rectilinear subre- 
gion of this plane. (141, 146) 

IMAGER, a SHADER that operates on pixel values. An imager 
would be used, for example, to convert RGB values to an- 
other format such as YIQ, (280) 

IMAGING, a step in the pixel production process of RENDERING 
that passes pixel values through a SHADER. In RenderMan 
this shader, the IMAGER, can be written by the user in the 
RenderMan Shading Language. (181) 

INCIDENT CONE. The cone within which light sources might 
contribute to a reflection in a particular direction. See also 
Figure 14.2. (302) 

INCIDENT VECTOR. The vector representing the direction from 
the viewpoint to a point on a surface. It is generally repre- 
sented as the vector I, and in the RenderMan Shading Lan- 
guage, by the global variable I. (226) 

INSTANCE (OF a SHADER), a shader invoked with a particular 
set of parameters. Several instances of the same shader 
can be in use on different objects. (211) 

INSTANCE (OF AN OBJECT), a copy of a previously described ob- 
ject For example, a "bowling pin" geometry' can be speci- 
fied, and several instances of the bowling pin created in a 
scene, each with different color and other attributes. (31, 
33,110,133) 
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Instance variables (OF a SHADER). The parameters to a 
SHADER that distinguish one LNSTANCE from another. 
( 212 ) 

INTERIOR VOLUME SHADER. A SHADER that calculates the effect 
on light as it passes through a VOLUME of material inside 
some object. (278) 

INTERNAL REPRESENTATION. The model of a “scene" construct- 
ed within a computer, as opposed to a physical scene as- 
sembled in the real world. (5) 

INTERPOLATING SPLLNE. A SPLLNE that passes through its CON- 
TROL POLNTS. The spline is said to interpolate those control 
points that it passes through. (90) 

INTERPOLATION. Calculating values or locations of intermedi- 
ate points as a smoothly varying function between end 
points. (74, 90) 

INTERSECTION (SET). That set containing only those elements 
in common between two or more sets. (126) 

JaGGIES. A form of ALIASING seen as the undesirable 
"stairstep" effect on object edges in an image. (10, 174) 

JITTERING, a technique for reducing the effects of ALIASING by 
randomly displacing samples from a uniform distribu- 
tion. (175) 

LEAF. In a HIERARCHICAL MODEL, a child with no CHILDREN of 
its own, indicating the lowest level of abstraction. (109) 

LEFT-HANDED (ROTATION). Turning an object about an axis in 
such a way that if a person's left thumb points along the 
axis of rotation, the other fingers curl in the direction of 
rotation. See also Figure 2.1. (21, 119) 

LENS, a transparent surface shaped to bend light rays to focus 
an IMAGE on a VIEWING SURFACE. (4) 

LEVEL OF detail. The degree to which the surface details of an 
object are available for scrutiny bv the viewer, measured 
simply as the size of the object (in pixels) on the display 
screen. (194, 195) 

LIGHT. The source of visual information about objects in the 
world The computer graphics model of light assumes that 
it travels in a straight line, can be bent, absorbed, or reflect- 
ed from a SURFACE, and that it has properties, such as col- 
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or, intensity arid direction, which can be altered by such an 
interaction. (2) 


LIGHT SOURCE SKA 
and color of li 
face. (210, 216, 


DER. A SHADER that calculates the intensity 
sent by a light source to a point on a sur- 


ght 


278) 

LOCAL COORDINATE SYSTEM. A COORDINATE SYSTEM that de- 
fines the origin and axis to be used in defining objects in a 
scene. GEOMETRIC TRANSFORMATION'S are defined relative 
to, and modify, the local coordinate system. (110) 

LOOP. In TRIM CURVES, a series of non-uniform, rational 13- 
splines (NURBs) in two dimensions. In polygons, a se- 
quence of vertice s. (249) 

MAIN BLOCK, a BLOCK of RenderMan routine calls bracketed 
by RiBeginO and RiEndO statements. .All RenderMan pro- 
grams include a main block. (48) 

MaTTE OBJECT. .An object or set of objects used to cut out 
"holes" in an image. The objects are not shaded, but rather 
form black Transparent areas in the image for later merg- 
ing with other images. This the three-dimensional equiva- 
lent of what is traditionally called a HOLD-OUT MATTE. (216) 




MESH, a two dimen 
ES defining a surra 

MIRROR DIRECTION. 


MAL. (3, 230) 


sional array of connected BICUBIC PATCH- 
ce. (94) 

he direction a light ray would follow af- 
ter being reflected from a perfect mirror. Specifically, the 
light source direction reflected about the SURFACE NOR- 




MIRROR REFLECTION. Light that leaves a surface only along the 


MIRROR DIRECTION 


( 3 ) 


MODES (OF OPERATION). States of a RenderMan program, as de- 
noted by BLOCKS vcith different rules and functions. For ex- 
ample, inside a WORLD BLOCK, options cannot be changed, 
but primitives can be declared and attributes set. Inside the 
MAIN BLOCK, but outside the world block options can be 
set, but primitives cannot be declared. (47) 


MOTION BLOCK, a sequence of RenderMan routine calls brack- 
eted by RiMotionBpginO and RiMotionEndO calls, specify- 
ing how the parameters of a procedure vary over a period 
of time. Motion bloqks are not nestable. (188) 
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MOTION BLUR. A blurring or "smearing” of objects seen in a 
photograph of a moving object. It produces a sense of mo- 
tion in an image and smooths the visual transition be- 
tween frames of an ANIMATION. (5, 186) 

NESTED BLOCK. A BLOCK containing another block of the 
same type. Certain types of blocks (e.g., the MAIN BLOCK 
and WORLD BLOCK) cannot be nested. Nestable blocks 
must observe strict nesting: every block must end before 
the end of any block containing it. (27, 48) 

NODE. In a HIERARCHICAL MODEL, an element of the hierarchy 
with CHILDREN of its own. (109) 

N'ON-PLANAR POLYGON. A POLYGON in which the vertices do 
not lie in a plane. (69) 

NORMAL (VECTOR). The vector perpendicular to a line, plane 
or surface at a given point. (73) 

NURB. A Non-uniform rational B-spline. A general class of 
PARAMETRIC SURFACE supported by the RenderMan Inter- 
face. See also TRIM CURVES. (83, 185) ' 

OBJECT. A set of SURFACES grouped together and treated as a 
single entity for purposes of shading, motion, duplication 
or assembling other objects. (2, 107) 

OBJECT DESCRIPTION. The process of specifying the geometry of 
an OBJECT. (31) 

OBJECT DESCRIPTION by INSTANCE. Describing an object as an 
INSTANCE of a specified object geometry. (31, 33) 

OBJECT DESCRIPTION BY PROCEDURE. A description of an object 
as a procedure to be called to create the object during REN- 
DERING. (33) 

OBJECT HANDLE. A tag returned by RiObjectBeginO by which a 
RETAINED MODEL can be INSTANCED. (133) 

OBJECT SPACE. The COORDINATE SYSTEM defined when work- 
ing with a parti cular object. (52, 111, 123) 


ONE-SIDED SURFACE. A surface that is only visible when it 
"faces toward" the viewer. (119) 

OPEN OBJECT. An OBJECT some surfaces of which can be 
viewed on both sides, e.g., a hemisphere. (118) 


[ 2 



' 


431 




OPTICAL SYSTEM. The parts of a MEWING device for focusing 
the \TEWING SURFACE (e.g., the LENS or PIN- 


light rays 
HOLE). (4) 


0:1 


OPTIONS. Elements of the GRAPHICS ENVIRONMENT concerned 
with characteristics of the entire image. Examples would 
be image resolution or viewing parameters such as cam- 
era location a nd field of view. (44, 45) 

ORIENTATION (OF A SURFACE). The angle of a surface at a given 
point relative to the viewer, affecting the light being re- 
flected at that point. Often (e.g., on the surface of an or- 
ange) this orientation can change from point to point caus- 
ing interesting effects in the reflected light. (6) 

ORTHOGRAPHIC PROJECTION. A PROJECTION in which distance 
from the viewer does not affect how large an object ap- 
pears, much like the effect of an infinitelv long telephoto 
lens. (S) 

PARABOLOID. A QUADRIC SURFACE created by sweeping a pa- 
rabola about ijts axis of symmetry. (60) 

PARAMETER LIST. A series of arguments to a RenderMan func- 
tion in TOKEN-VALUE PAIRS, terminated bv the special to- 
ken RLNULL. (39) 

PARAMETER space, a two-dimensional COORDINATE SYSTEM 
mapped onto a surface. In the RenderMan Interface, coor- 
dinates in parameter space are expressed as u and v, and 
range from 0 to 1 in both directions for most primitives. 
(245) 


PARAMETRIC SURRaCE. a type of PRIMITIVE SURFACE defined as 
a polynomial blend of CONTROL POINTS (a PATCH or a 
MESH). (86, 59)1 

PATCH, a curved surface with four vertices and four edges 
that can be mathematically defined in terms of 16 CON- 
TROL POINTS. (86) 

Parent. For a given element in a HIERARCHICAL MODEL the el- 
ement at the next level up with which it is associated. For 
example the "toes" of a "foot" object would share the 
same parent. (109) 

PERSPECTIVE PROJECTION. The PROJECTION of a three-dimen- 
sional scene onto a two-dimensional plane in which ob- 
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jects near the viewer appear larger than objects of similar 
size that are farther away. (8) 

PHONG INTERPOLATION. The method of generating a SURFACE 
NORMAL vector at each point on a POLYGON by INTERPO- 
LATING between normals that are provided at the polygon 
VERTICES. (74) 

PHONG SHADLNG. a SHADING technique in which each point 
on a surface is shaded by using SURFACE NORMALS comput- 
ed with PHONG INTERPOLATION. (74) 

PINHOLE, a small hole in an opaque surface allowing only cer- 
tain light rays to pass through. Its effect is similar to a 
LENS, focusing an image on a VIEWING SURFACE. (4) 

PIXEL. A "picture element" of a viewing screen. A rectangular 
screen is composed of thousands of pixels, each represent- 
ing the color of an image at a given point on the screen. 
The pixel value calculated and stored for each pixel typically 
consists of several CHANNELS such as the red, green, and 
blue components of its color, and/or opacity or coverage 
information. See also PROJECT. (8, 172) 

PIXEL ASPECT RATIO. The ratio of the width to height of a physi- 
cal pixel in a display device. (156) 

PLANAR (POLYGON). A POLYGON in which all vertices lie in 
the same piane in three-dimensional space. (69) 

POINT LIGHT SOURCE, a light source that distributes light even- 
ly in all directions from a specified point. The intensity of 
its light arriving at a surface diminishes with the square of 
the distance from the point to the surface. (221) 

POINTS-POLYGON FORM. A way of specifying a set of polygons 
(e.g., when defining a polyhedron) in terms of a previous- 
ly defined set of points. In other words, each vertex is de- 
fined only once, and used many times (by all the polygons 
that share it). (79) 

POLYGON, a simple type of PRIMITIVE SURFACE composed of 
three or more VERTICES connected by straight EDGES. (59) 

POLYHEDRON. A three-dimensional object with POLYGONal 
faces. (69) 

PRIMITIVE OBJECT. An OBJECT consisting of a single PRIMITIVE 
SURFACE. (107) 
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Primitive so: 


ID. In CONSTRUCTIVE SOLID GEOMETRY (CSG), a 


SOLID defined entirely by PRIMITIVE SURFACES. (126) 

PRIMITIVE SURFACE, a geometric element from which com- 
plex surfaces can be specified. There are three kinds of 
primitive surfaces in RenderMan: QUADRIC SURFACES, 
POLYGONS' and PARAMETRIC SURFACES. (59) 

PROCEDURAL MODEL, a specification of an object geometry in 
terms of a procedure. See also OBJECT DESCRIPTION BY PRO- 
CEDURE. (94, 201) 

PROCEDURAL DEJECT DESCRIPTION. See OBJECT DESCRIPTION BY 
PROCEDURE (33) 

PROJECT. In computer graphics, to cast a three-dimensional 
scene onto a two-dimensional plane. Each point in the 
scene is mapped to a corresponding point on the plane. 
Those surfaces not obscured by other surfaces form the re- 
sulting PROJECTION. The IMAGE is formed from this projec- 
tion by taking (color) SAMPLES at regular intervals and gen- 
erating PIXjEL values accordingly. This is our model of vi- 
sion, which captures light rays from a three-dimensional 
scene on tpe retina of the eve or the film of a camera. 
(4, 146) 

PROJECTION. A 
mensional 
surfaces in 
See also PRO 


RenderMan 
TION. (59) 


two-dimensional representation of a three-di- 
scene, obtained by mapping points on visible 
the scene to corresponding points on a plane. 
ECT. 

QUADRIC SURFACE. A type of PRIMITIVE SURFACE definable by- 
quadratic equations. Examples are spheres and cones. All 
quadric surfaces are SURFACES OF REVOLU- 


QUANTIZATJON. Reducing an arbitrarily precise SAMPLE value 
to one of a number of discrete values. For example, while 
pixel values of an image as computed may be arbitrarily 
precise, digital DISPLAYS can display pixels at only a finite 
number of discrete levels. (10, 173) 

RADIOSITY. A SHADLNG technique that computes the light ar- 
riving at a surface by analyzing the distribution of light en- 
ergy in a sceie. (304) 

RASTER. The arrangement of PIXELS in a DISPLAY MONITOR as 
a two-dimensional array or grid of pixels. (9, 172) 
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Raster SPACE. The COORDINATE SYSTEM of the rendered im- 
age used when displaying the image on a monitor. Its ori- 
gin is the top left comer of the top left pixel, and each pixel 
has a non-negative integer location. (53, 122) 

RAY TRACING. A RENDERING algorithm that computes the col- 
or of a pixel by casting an imaginary ray back into the 
scene from the viewpoint, until it hits an object, and then 
recursively casting ravs tow r ard light sources and other ob- 
jects. (260) 

REFINEMENT PROCEDURE. The procedure used in a PROCEDUR- 
AL MODEL to specifv a portion of an object in more detail. 
( 201 ) 

REFLECTION map. An image mapped onto a surface to simu- 
late the mirror-like reflections of other objects. 
(257, 261, 320). 

REFRACTION. The change of direction of light as it passes 
through a transparent SURFACE. (3) 

RELATIVE index OF REFRACTION. A measure of how much a 
light ray will be REFRACTED when passing through the sur- 
face between two materials. (328). 

RENDERING. The process of generating a synthetic image of a 
scene given a precise description of the geometry and oth- 
er characteristics of the scene. (5, 11, 137) 

RESOLUTION. The degree of GRANULARITY of a DISPLAY MONI- 
TOR specified by the number of rows and columns of PIX- 
ELS in the display. (9) 

RETAINED MODEL, a geometric description of an object that 
may be used to make INSTANCES of the object. (133) 

ROOT. In a HIERARCHICAL MODEL, the highest level of abstrac- 
tion. In RenderMan, the scene itself. (109) 

ROTATION, a transformation turning an object around an ax- 
is. (21) 

ROUGHNESS. The property of a surface causing SCATTERING of 
light as it reflects off of it. A surface from which most out- 
bound rays leave near the MIRROR DIRECTION will appear 
shiny; one with a great deal of scatter will appear rough. 

(7) 
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SAMPLE, a measurement or snapshot of a particular property 
at a specific point in time or space. For example, a PIXEL 
can represent a sample of color at a point in space, as pro- 
jected onto a two-dimensional surface. (9, 173) 

SAMPLING. The process of determining a SAMPLE or series of 
samples over a given region of time or space. For exam- 
ple, determining a color value (the sample) to represent 
the color of a projected image at a point in the IMAGE 
PLANE. (176) 

SCALING, a transformation changing the size of an object in 
the x, y or z directions. (113) 

SCATTERING. The dispersal of light in many directions upon 
being reflected from a point on a surface. (3) 

SCENE DESCRIPTION. The process of specifying a scene to be 
RENDERED in terms of objects, light sources and viewing 
devices. (12, 59) 

SCREEN SPACE. A unitless, device-independent two-dimen- 
sional COORDINATE SYSTEM on the IMAGE PLANE after PRO- 
JECTION. (53, 122) 

SCREEN WINDOW. The two-dimensional rectangular region of 
the IMAGE PLANE that contains the PROJECTION of a scene 
to be rendered. (137, 141, 146) 

SHADER. A part of the RENDERING program that calculates the 
appearance of visible surfaces in the scene. In Render- 
Man, a procedure written in the RenderMan Shading Lan- 
guage and used to compute a value or set of values (e.g., 
the color of a surface) needed during rendering. (117, 210, 
211,273) 

SHADING. The part of RENDERING concerned with the appear- 
ance of each surface as seen in the output image. (209, 239) 

SHADLNG LANGUAGE. A language employed to write SHADERS. 

( 12 ) 

Shading normal, a surface normal used for the purpose 
of SHADLNG calculations. (It may differ from the actual 
GEOMETRIC NORMAL in order to simplify shading calcula- 
tions, or to achieve special shading effects). It is generally 
represented by the vector N, and in the RenderMan Shad- 
ing Language, by the global variable N. 
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SHADING PIPELINE. The three basic parts of the SHADING pro- 
cess: illumination (characterizing sources of light), reflection 
(determining local surface characteristics affecting the col- 
or and direction of light) and atmospheric effects. (209) 

SHADING rate. An ATTRIBUTE of a surface that determines 
how often its appearance must be calculated during SHAD- 
ING. In RenderMan this is specified as an area, in pixels. 
(214) 

SHADOW map. An image used by a light source to determine 
information for determining whether a point on a surface 
falls within a shadow cast bv another surface. (257, 268, 
320) 

SHAPE. The geometry of an object or set of objects as specified 
by surface primitives. (209, 239) 

SIBLINGS. In a hierarchical model, two or more CHILDREN 
with the same PARENT. (109) 

SKEW. To slant an object at an angle. See also illustration on page 
223.(113) 

SOLID, a set of points in three-dimensional space with a sur- 
face unambiguously separating points in the set from 
those not in the set. (126) 

SPECULAR (REFLECTION). Reflected light concentrated near, but 
not confined to the MIRROR DIRECTION. A specular reflec- 
tion is brightest when seen from viewpoints along or near 
the mirror direction, and becomes dimmer away from 
that direction. (3, 230) 

SPHERE. A QUADRIC SURFACE created by sweeping a circle 
about an axis that bisects it. (60) 

SPLINE. A curve mathematically defined as a polynomial 
blend of a set of CONTROL POINTS. The splines used in Ren- 
derMan are based on cubic splines, which are specified us- 
ing cubic polynomials over four control points. There are 
four kinds of cubic splines named in RenderMan: BEZIER, 
B-SPLINE, CATMULL-ROM, and HERMITE, each differing in 
the way the control points are interpreted. (90) 

SPOTLIGHT, a light source with a specified location and direc- 
tion. Its light is distributed as a cone-shaped beam, whose 
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intensity falls off with the angle from the center of the 
cone. (2 22 1 

STACKED (GEOMETRIC TRANSFORMATIONS). TRANSFORMATIONS 
that are performed in the reverse order in which the}' are 
declared. In RenderMan, the CURRENT TRANSFORMATION 
is a stack. '27) 

Subdivision of polygons). The process of dividing poly- 
gons into smaller polygons to compensate for the prob- 
lems inherent in FLAT SHADLNG. (71) 

SUPERS AMPLING. A technique to reduce ALLASLNG by taking 
several SAMPLES of a scene for each pixel and FILTERING 
the resulting values to obtain the pixel value. (174) 

SUPPORT (OF U FILTER FUNCTION). The "width" of a FILTER 
FUNCTION; i.e., the area around a pixel center outside of 
which a SAMPLE will be given 0 weight. (176J 

SURFACE. Thel set of points in space where LIGHT interacts 
with an OBJECT. In computer graphics this is generally- 
modeled as a set of simpler surface shapes that can be 
mathematically described. (2) 


Surface elem 

quire only 


ENT. A piece of a SURFACE small enough to re- 
a single color value, either because it is very' 
small or because its shading varies slowly. (295, 326) 

SURFACE normal. The vector, usually denoted by N, perpen- 
dicular to a surface at a given point. (226) 

SURFACE OF REVOLUTION. A surface created by sweeping a 
curve about an axis. (60) 

SURFACE SHADER, a SHADER that calculates the color of light 
reflecting from a point on a surface in a particular direc- 
tion. (215, 2.15) 

SWEEP ANGLE. The angular extent (often 360°) to which a 
curve is swept about its axis of rotation to create a SURFACE 
OF REVOLUTION. (60) 

TEMPORAL aliasing. The undesirable "strobing" effect in an 
animated sequence caused by abrupt changes in a scene be- 
tween frames. Temporal aliasing can be eased by MOTION 
BLUR to help the eye make a smooth transition between 
frames of a moving object. (186) 
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TEMPORAL SAMPLE, a sample of a scene's configuration at a 
given moment in time. (186) 

TENSION. The tightess with which a cubic SPLINE or a PATCH 
follows its CONTROL POINTS. (92) 

TENSOR PRODUCT. The mathematical function used to gener- 
ate a curved surface from two orthogonal sets of splines. 
(92) 

TEXTURE. The properties of a surface that affect the local color 
or appearance at different points on the surface. For exam- 
ple, a "wood" texture causes the color of the surface to be 
darker or lighter from point to point simulating wood 
grain. (6) 

TEXTURE COORDINATES. The coordinates of a point on a sur- 
face given in terms of a two-dimensional COORDLNATE SYS- 
TEM mapped onto the surface. See Figures 12.1 and 12.2. See 
also Parameter space. (240) 

TEXTURE MAP. An image that, when mapped onto a surface, 
specifies its TEXTURE. (13, 319) 

TEXTURE MAPPING. Mapping a previously computed image on- 
to the surface of an object. The image is referred to as a TEX- 
TURE MAP. (240) 

TOKEN-VALUE PAIR, a common construct in the RenderMan 
Interface, used to specify optional arguments to a proce- 
dure, consisting of a token (a specific string of characters) 
followed by the desired value. (19, 39) 

TORUS. A QUADRIC SURFACE created by sweeping a circle about 
an axis that does not intersect the circle. (60) 

TRANSFORMATION, a function applied to the points in a CO- 
ORDLNATE SYSTEM to redefine their coordinates. This is 
usually used to convert between coordinate systems or for 
ROTATION, TRANSLATION, SCALING, etc. (21) 

TRANSFORMATION BLOCK, a sequence of RenderMan routine 
calls bracketed by calls to RiTransformBeginO and RiTrans- 
formEnd(), which save and restore the CURRENT TRANSFOR- 
MATION. Transformations invoked within the block affect 
only those objects created after the transformation and be- 
fore the end of the block. Transformation blocks can be 
nested. (47) 
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TRANSFORMAT] 

TRANSFORM/ 


DN MATRIX. A 4 x 4 matrix used to specify a 
ATTON between COORDLNATE SYSTEMS. (115) 


TRANSFORMATI 
point coor 
mation sha|d 
FORMATION 


Translation. 


DN SHADER. A SHADER that recalculates the 
dinates in a COORDINATE SYSTEM. The transfor- 
er is concatenated onto the CURRENT TRANS* 
(279) 


A TRANSFORMATION changing the location of 


an object. (21) 

TRANSPARENT. The property of a surface allowing light to pass 
through it. ( 5) 

TRIM CURVE. A surface defined by a set of LOOPS defined in the 
parameter soace of a NURB. Each loop limits the surface to 
just the points inside or outside the loop. The total surface 
consists of tjhe collection of these points after all loops are 
applied. (10-j, 249) 

u DIRECTION. In the direction of the u axis in the PARAMETER 
SPACE of a surface. (92) 

UNIFORM (INSTANCE VARIABLES). The parameters of a SHADER 
that have the same value for all points of the surface to 
which the shader is attached (212, 242) 

UNION (SET). That set containing ali the elements of two or 
more sets. (126) 


VARIANCE, a statistical measure of the accuracy of a SUPER- 
SAMPLED pixel value. RenderMan allows a tolerance to be 
set to guarantee an acceptable level of variance. (179) 

VARYING (INSTANCE VARIABLES). Those parameters of a SHAD- 
ER with values that may change from point to point on a 
surface. For example, a geometric description of a surface 
may define a variable temp that varies from point to point 
on the surface, and a shader may use temp as one of its pa- 
rameters. (21 2, 242) 


v DIRECTION. In the direction of the v axis in the PARAMETER 
SPACE of a bicubic surface. (92) 

VERTEX, a point where two or more EDGES meet, specified by 
the x, y and 2 j coordinates of its location. (19) 

VIEWER. A person or device receiving and interpreting light 
reflected fronji a scene. In a simplified model of optics, the 
viewer is represented by a VIEWING DEVICE. (2) 
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VIEWING DEVICE. In a simplified model of computer graphics, 
the device used to view a scene, usually an abstract eye or 
a VIRTUAL CAMERA model (4). 

VIEWING DIRECTION. The direction the viewer is pointed with- 
in the scene. (141) 

VIEWING LOCATION. The location of the viewer relative to 
the scene. (141) 

VIEWING SURFACE. The part of a VIEWING DEVICE where the 
image actually forms, e.g., the retina of the eye, or the film 
in a camera. (4) 

VIEWING TRANSFORMATION. The TRANSFORMATION that trans- 
forms points from WORLD SPACE to CAMERA SPACE. (142) 

VIEWPOINT. The VIEWING LOCATION. 

VIRTUAL camera. The imagined device with position, orienta- 
tion and other characteristics that project the scene into 
two dimensions to form an image. (137, 141) 

VOLUME. A region of space filled with a material, e.g., air fog 
or jello. (Contrast to a SURFACE, which surrounds the vol- 
ume). (233) 

VOLUME SHADER, a SHADER that calculates the color and in- 
tensitv of light as it passes through a VOLUME. (210, 234, 
278) ' 

WORLD BLOCK. A BLOCK of RenderMan routine calls bracket- 
ed bv RiWorldBeginO and RiWorldEndO statements. Out- 
side of the world block geometric SURFACE PRIMITIVES can- 
not be declared. Inside, global OPTIONS cannot be set. Upon 
RiWorldEndO the scene is rendered and the scene data 
cleared. World blocks cannot be nested. (49) 

WORLD SPACE. A COORDINATE SYSTEM used for SCENE DESCRIP- 
TION, i.e., placement and orientation of the defined objects 
in space. (52, 123) 
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. opera :qt (shading language), 299, 359 
A operator (shading language), 299-300, 359 

A 

absO function, 312 

absorpnpn. 2-3 

The A'ryss. 387 

acosi « function, 312 

aggregate objects, 31-33, 107-108 

4;mZw program, 142-143, 144 

anas in o 

denned, 174 

:ii terms and, 10, 173 174-175 
jittering and, 175 
literature on, 191 
point sampling and, 173.. 174 
reducing, 348-349 
See disc motion blur 
alpha 

storing in pixels, 156, 173-174 
See also opacity 
ambientO] function 
d eclairs non of, 315 
illuminance construct and, 303-304 
ambient light sources, 218-219, 303-304, 315 
ambient light source shader, 218-219 
definition of, 337-338 
ambient reflection, 22S, 229, 230 
analog signal processing, textbooks on, 191 
anamorphic wide-screen movie formats, image 
distortion of, 161 
animation 

defined, 33 
examples, 387 




Index 


simple program, 33-34 
See also frames 
anti-aliasing. See aliasing 
aperture, 5, 8 

approximating curved surfaces. 193 

determining quality of approximation, 
171-172 

See also parametric surfaces; programs, for 
surface of revolution generation; quadnc 
surfaces 

areaQ function, declaration of, 327 

area light sources, 224-225 

area light source shader, 224-225, 307-30S 

arithmetic, on special data types, 298 

array data type, 41 

asinO function, 312 

aspect ratios 

frame aspect ratio, 153, 158-159, 166 
default, 166 
enforced, 161-163 
image aspect ratio, 157-159 
as option. 45-46 
pixel aspect ratio, 
default, 156, 166 
specifying, 139, 156-157, 166 
atanO function, 312 

atmosphere shaders. See volume (atmosphere) 
shaders 

atmospheric effects 

natural images and, 3-4, 233 
rendered images and, 7, 210, 233-236 
See also volume (atmosphere) shaders 
attribute blocks 

aggregate objects and, 108 
defined, 47 


nesting, 48, 49j-50 
Attributes 

declaring, 50 
defaults, 44 
defined, 44, 46] 

graphics environment and, 23 

motion blur and, 191 

non-standard, 46 

of objects, 44, 4b, 47 

options vs., 47 

setting, 46 

shaders as, 212 

for shading, 234—215 

stacking, 29, 47, 50 

when thev can be set, 47, 46 


13 


basis matrices, for bijmbic patches, 92-93 
basis solid, 130 
Beta splines, 92 
bevelled surface displacement shader, defini- 
tion of, 363- $>66 
Bezier splines 

for bicubic patches, 90 
as non-uniform rational B-splines 
(NURBsj, 105 
Bezier spline segmentation 

for bicubic patch meshes 95-97, 99 
with wrapping, 103 
bicubic patches 

basis matrices, 92-93 
Beta splines, 92 
Bezier splines, 90 
B-splines, 91 
Cardinal splines, 92 
Catmull-Rom splines, 91 94 
declaring, 87-88 
defined, 87 

geometrv matrix (control hull), 87, 88, 90, 
92,95 

geometry vector (control hull), 90 
as height fields, 24p 
Hermite splines, 91-92 
interpolation for, 245-246 
parameter space ofj 245-246 
as product of orthogonal curves, 92 
programs for generating, 88, 89, 94 
Catmull-Rom surface, 94 
selecting a type, 92-t93 
step values for, 93 
types of, 90-92 


bicubic patch meshes, 94-103 

Bezier segmentation, 95-97, 99 
B-spline segmentation, 97, 98 
Catmull-Rom segmentation, 97-98 
dosing manually, 100 
defining surfaces with, 98-99 
evaluation window, 95, 99 
geometry matrix (control hull), 95 
as height field, 246 
Hermite segmentation, 98 
interpolation for, 246 
overview of, 94-95 
parameter space of, 246 
smoothness of curved surface generated. 95 
surface of revolution generation usinc. IX 
101 

with wrapping, 101-103 
wrapping, 98, 100-103 
bilinear interpolation, 86-87 
bilinear patches 

as alternatives to polygons, 88, 90 
for approximating curved surfaces 90 
bevelling perpendicular, 363-366 
declaring, 87-88 
defined, 86 
as height field, 246 
interpolation for, 86-87. 245-246 
parameter space of, 245-246 
rrocram for generating with texrurmc 
252-253 

bilinear patch meshes 
dedaring, 98 
as height field, 246 
interpolation for, 246 
parameter space of 246 
Blinr. Jim, 237, 271 
blocks, 47-51 

attribute blocks, 47, 48, 49-50, 1 OS 
frame blocks, 50-51 
main block, 48 
motion blocks, 188-191 
nesting of, 27, 48, 49 
option blocks, 50 

valid block types for RenderMan Interface 
procedures, 57-58 
world blocks, 48-49, 51, 109 
blue-marble surface shader, 354-356 
blur 

depth of field and, 5, 8 
See also motion blur 

boilerplate RenderMan program, 54-55 
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Index 


boilerplate RenderMan programs, for defining 
view parameters, 138-141, 167-169 
Boolean data type, 41 
boundary, defined, 69 
boundary representation, defined, 126 
bounding boxes 

calculating for fractal triangle, 207-2C8 
data type for, 41 
declaring, 124-125 

for level of detail calculation, 195-196 
defined, 195 
specifying, 150-151 
So^/iingBallO program, 130-131 
bowling pm 

bicubic patch mesh, 100, 101 
with wrapping, 101-103 
hyperboloid, 64— 65 

with texturing, 253-256 
polygonal, 71, 72, 74-76 
polyhedral, 30-82 
surface shader for, 375-378, 379 
box liter function, 176-1 78 
brea c construct (shading language), 301 
B-sp ines 

dr bicubic patches, 91 

non-uniform rational B-splines (NURBs >. 

85, 103-105 

as uniform bicubic patches and patch 
meshes. 105 

3-splne segmentation, for bicubic patch 
meshes, 97 

bumpQ function, declaration of, 322-323 
bump mapping, 258-260 
alternative for, 259-260 
bowling pm surface shader with, 375-37S. 
379 

creating a bump map, 259 
ii :erature on, 271 
n ap access function, 322-323 
p .tted surface shader with, 375 
purpose of, 257, 258-259, 320 
texture mapping vs., 258-259 


header file (riir), 40 
RenderMan Interface and, 17-18 
resemblance of shading language to, 
283-284, 287-288, 298-301 
vanable-length parameter lists, 39-40 
CAD, enhanced, RenderMan and, 386 


calcuiatenormalO function, declaration of, 330 
call-by-value declarations, 24-25 
camera (physical), 167 
camera (virtual), 141-154 
clipping planes, 145-146 
defined, 137, 141 
describing, 145-148 

program for, 148-149 
direction of, 144 

field of view, 141, 147-148, 152-154 
general transformation for, 144-145 
graphic representation of, 167, 168 
orientation of, 140 
perspective projection, 149-154 
placement of, 140 

simple program for, 142-145, 154-155 
projection model, 146-148 
roll, 144 
rotation, 144 

shutter, opening, dosing, 190 
translation, 143-144 
viewing transformation for, 141-142 
See also depth of field; lenses; motion blur; 
screen window; view 
camera models 

used by RenderMan Interface, 14, 141 
used in computer graphics, 7-8 
See also camera (physical); camera (virtual) 
camera position, global variable for, 294-295 
camera space 

as default coordinate system, 119 
defined, 52-53, 123 

returning local coordinate system to. 117 
transforming world space to, 141-142, 
144-145 
Cardinal splines, 92 
Catmull-Rom filter function, 176-178 
Catmull-Rom splines 

for bicubic patches, 91 
program for generating Catmull-Rom 
surface, 94 

Catmull-Rom spline segmentation, for bicubic 
patch meshes, 97-98 
ceilQ function, 312 
channels 

defined, 319 
defining, 42-43 
character strings 

RtTokens versus, 42 
in shading language, 288 
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checkerboard surface shader, definition of, 
343-346 

children (hierarchical), defined 109 
G (global variable;. 292, 296 
CIE XYZ color representation, 289 
O (global variable;, 292, 296 
clampO function, 312 
clamping, defined. 163 
clearing 

current transformation, 116-117, 143 
viewing rransformari or. 143 
clipping planes.. 143-146 


compO function, declaration of, 330-331 
composite objects. See aggregate objects 
composite solid objects. See Constructive Solid 
Geometry (CSG) 

compound objects. See aggregate objects 
computer-aided design (CAD), enhanced, 
RenderMan and, 386 

computer graphics. See graphics (computer 

concave polygons, 69-70 

cones 

declaring, 62-63 
defined, 60 

parameter space of. 246-24' 


accessing color components, 330-331 
color mixing, 331 

shading, coloring and lighting functions, 
315-319 
color separations, 2 81 
color space 

monochromatic, 43 
multi-channel, 42-43 
commutative object declaration, 27 
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convex polygons, 69-70 
Cook, Rob, 237, 271 , 285 
coordinate systems, 52-53, 122-124 

axes of, as a three-dimensional cursor, 111 
conversion function, 329 
default system, 119 

for shading language, 291 
geometric transformations and, 122 
handedness of. 


clockwise order, verte> specification in, 19 

a? special case of hyperboloids. 63-64 

closed objects defined , 116 

constant shading, 213 

ciouds surface shader, 2S2-2S5 

constant surface shader 

coherence, of surfaces, 59 

alternate, 362-363 

color 

definition of, 334 

as attribute, 46 

invoking, 1 8, 232 

constar: 16, 215, 232. 334, 362-363 

purpose of. 232 

current coior 44,215 

Constructive Solid Geometry (CSG;. 125-135 

default. 22 

declaring composite solid objects, 126-133 

global variably for, 292, 294 

difference operation 126,130-132 

light and. 2-3 

intersection operation, 126, 126-13; 

nonlinear encqdmg of. 179-180 

shading, 132-133 

quantization of, 175, 152-1 64 

union operation, 126 13C 

Transforming before, 181 

declaring solid obiects, "2t^l27 

of reflections, 22t?-227 

defined, 14, 11 Q, 125-126 

representation of, 8-9.42-43 156, 173 

programs, 

220-22^ 244. 289 

bowling ball generation, 1?1 

default, 43 

solid partial sphere anc cylinder ; 

shading and, 6 

generation, 126-129 

specifying, 22-13. 42-43. 213. 227, 345-349 

solid surface of revolution eeneration, 

See also pixels 

127 

CoiorCubeV) program, 29-32. 33 

continue construct (shading language 301 

coior data type, 281 , 2S4. 289 

contrast, 173, 184 

arithmetic on, 296 

control constructs (shading language), 255, : 

comparison of, 299 

300-301 

cross product of, 299-300 

control hull. See geometry matrix; geometrv 

dot product of, 299 

vector 

coloring, images. 22-23 

control points. See geometry matrix; geometry 

coloring functions 

vector '■ 
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default, 112, 119 

'eft- vs. right-handed coordinates, 
119-122 
homogeneous coordinates, 88 
naming, 123 
shaders and, 348 
for shading language, 289-290 
See 4 Iso camera space; color space; local co- 
ordinate systems; mapping; object 
space; parameter space; raster 
space; screen space; texture space; 
world space 

copying objects, 31, 110, 133-134 
cosO function, 312 

coverage information, specifying, 156 

cropping, 139, 162-164, 166 

crop window, definition of, 162 

cross product (shading language), 299-300, 359 

Crow, Frank, 191 

Cs (global variable), 292, 296 

CSG. Set Constructive Soiid Geometry 

cubes 

denned, 24 
See p/so unit cubes 
current polor, 44, 213 
current pispia cement shader, 260 
current Instance of shaders, 212 
current level of detail, 196, 196 
current ppacity, 213 

surface shader, 231 
transformation, 53, 109, 110-112 
clearing, 116-117, 143 

majrking as viewing transformation, 140-141 
procedures affecting, 112-116 
replacing, 117 

also viewing transformation 
volume shader, 235 
curved surfaces 

approximating, 193 

I determining quality of approximation, 
171-172 

See also parametric surfaces; programs, for 
surface of revolution generation; 
quadric surfaces 
curves, tension of, 92 
curve trimming 

declaring, 249-250 
defined, 103, 249 
cylinders 

declaring, 63 
defined, 60 


current 

current 


see 

current 


parameter space of, 246-247 

solid partial, 128-130 

as special case of hyperboloids, 64 


D 


database capabilities, of RenderNlan Interface, 
15-16 

data handles, scope of, 51 
data types, 40-43 

defined vs. underlying types. 40-41 

function pointers, 42 

header file, 40 

opaque types, 41 

"Rt" prefix explained, 40 

scalar types, 41 

for shading language, 251, 2S4, 2SS-290 
vector types, 41 
See also individual data tyr yes 
declarations of objects 

call-by- value nature of, 24-25 
commutative nature of, 27 
for moving objects, 190 
and procedures affecting obiect characteris- 
tics, 23 

default settings 
attributes, 44 
basis matrix, 93 
camera placement. 14C 
clipping planes, 145 
color, 22 

color representation, 43 
coordinate system, 119 
handedness of, 112, 119 
for shading language, 291 v 

curved surface approximation criteria, 172 
rile name (image), 19 
til ter function, 176 
focal length, 147, 148 
frame aspect ratio, 166 
illuminance, 302 
instance variables, 212, 297 
light source, 23, 21 8 

ambient light source, 219 
distant light source, 21 . 221 
on/off state of, 217 
point light source, 221 
options, 44 
overview of, 23 
pixel aspect ratio, 156, 165 
ratio of samplesipixels, 176 
resolution, 166 
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screen window, 140, 152, 158, 167 
shader function type, 288 
spotlight location, 269 
storage classes, 297 
surface appearance, 23 
surface shader, 231 
texture range, 294 
\hew, 19-20, 139 

volume (.atmosphere) shader, 23 5 
deformation (transformation' shaders, 117-118, 
278-279 

degreesO function, 312 
density, of shading, 214-215 
dented surface displacement shader 
definition of, 350-352 

See also gouged surface displacement shad- 
er; pitted surface displacement 
shader 

depth (r value), function for computing. 329-330 
depth (r value), storing in pixels, 156, 173 
depthO function, declarator of, 329-330 
depth cues, and atmospheric effects on light, 3-4 
depth-cue volume shader, 236, 237 
definition of, 341-342 
depth of field 

defined, 5, 8, 45. 165 
f-stop and, 1SE4186, 187 
specifying, IS 5- 186 
DerivO function, declaration of, 313 
derivatives 

functions for, 313 
global variables for, 295 
destination, specifying for images, 154-155 
detail. See level of detail 
difference operation (Constructive Solid 
Geometry), 126, 130-132 
differential surface area function, declaration 
of, 327 

diffuseO function 

declaration of, 316 
using, 335-336 
diffuse reflection 

appearance of, 229 
artificial "computer' look of, 231 
calculating, 316 
defined, 3, 230 
specifying, 228 
See also matte surface shader 
digital images. See images 
digital signal processing, literature on, 191 


direction, of camera, 144 
disks, declaring, 62-63 
displacements, defined, 45 
displacement shaders, 118, 259-260, 278 
bevelled surface, 363-366 
dented surface, 350-352 
drooping surface, 370 
embossed surface, 383 
ferrule, 361-383 
gouged surface, 376, 379, 383 
pitted surface, 375 
threaded surface, 366-367 
display 

defined.. 9 
describing. 154-156 
filling with a scene, 160 
windowing onto, 161 
distanced function, declaration or, 327 
distant light sources, 20-21 , 221 
distant light source shader, 210, 219-221, 308 
definition of, 338-339 
distorted images 
avoiding, 160 
cause of, 158 
using, 161-162 
dithering, 183, 184— 185 
DomesO program, 196-199, 200 
do: product (shading language , 299 359 
dPoL (global variable), 292, 296 
dPcv (global variable), 292, 296 
drooping surface displacement shader, 
definition of, 370 
(global variable), 292, 296 
Du() function 

declaration of, 313 
functioning of, 314 
duplicating objects, 31, 110, 133-134 
ch (global variable), 292, 296 
Dv() function 

declaration of, 313 
functioning of, 314 

E 

£ (global variable), 292, 296 

easy surface shader, definition of, 362-363 

edges, defined, 69 

embossed surface displacement shader 
definition of, 383 

See also gouged surface displacement shader 
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Index 


emission. See light emission 
environment 

of light source, 6 

See also geometric transformation environ- 
ment; graphics environment 
environment) function, declaration of, 325-324 
environment (reflection) mapping, 260-267 
creating an environment map, 262-267 
drawbacks of ray tracing, 261 
literature on, 271 
map access function, 323-324 
metal shader with environment mar. 
379-381 

purpose of, 257, 260-262, 320 
See also specular reflection (mirror 
reflection) 

eraser surface shader, definition of, 385 
eroded surface shader, definition of, 352-353 
error handling, 38-39 
evaluation window (bicubic patch mesh) 
for Bezier splines, 95-97, 99 
for B-spiines, 97 
for Catmull-Rom splines, 97-98 
defined, 95, 99 
for Hermite splines, 98 
wrapping and, 100-103 
expj) function, 312 
exposure. 179-180 
exp’essions (shading language), 298 
extensibility, of RenderMan Interface, 15 
exte rior volume shaders, 235, 278 
eve position, global variable for, 294-295 


face forwardO function, declaration of, 325 
face ted appearance, reducing, 71-77 
false contours, 10, 184-185 
Faux, I.D., 65 

ferrule displacement shader, 381-383 
ride lity, of pixels, 178-179 
riel# of view 

changing, 147-148, 152-154 
defined, 4, 141 

settings corresponding to various camera 
lenses, 150 
filament surface shader, 367-368 
file name (image) 
default, 19 
specifying, 155 

filefe 


ri.h , 38, 40 
ri.pic , 19 

sending output of different frames to 
different files, 33 

storing images in, 155, 160, 161, 165 
film frame. See screen window 
filter functions, 176-178 
filtering, 9-10, 173, 174-179 
fisheye lens, field of view setting corresponding 
to, 150 

flat shading, 71-78 

flipping function, declaration of, 328 

float data type, 288 

float math function, 312 

floating point data type, 41, 244, 2S8 

floorQ function, 312 

focal length 

defined. 146 

depth of field and, 1S5, 1S6 
fixed setting for. 147, 145 
focal point, 146 
focus 

depth of field and, 5, S 
projection of light and, 4 
fog volume shader 236-237 
definition of, 342-343 
for statement (shading language), 301 
FractalO program, 203-208 
frame aspect ratio, 153, 158-159, 166 
default, 166 
enforced, 161-162 
frame blocks, 50-51 

frame buffer, displaying images in a, 154-155 

FrameCameraO program, 1 48-155 

frames 

begin rendering, 33, 50-51 
cropping, 139, 162-164 
defined, 33, 137, 159 
frame blocks, 50-51 
images vs,, 159-160, 165, 166 
purpose of, 159 

screen window's relationship to, 159 
sending output of different frames to 
different files, 33 
shape of, specifying, 153 
stop rendering, 33, 50-51 
tiling, 162-163 

fresnelO function, declaration of, 328-329 
f-stop, depth of field and, 185-186, 187 
function pointers, 42 
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functions 

filter functioAs, 176-178 
in shading language, 

color fun pons, 330-331 
defining, 1287-288 
geomerrii functions, 325-330 
map access functions, 319-324 
mathematical functions, 311-314 
print function, 332 
shading, coloring and lighting 
functions, 315^319 
Sec also noise'} function; procedures; 
programs; shaders 


Gaussian filter function. 176-178 
general linear transformations, 11 
geodesic dome pro, 


116 

pam, 198-199, 200 


geometric data, passing across the interface, 18 


geometric runcnonf 
coordinate sysije: 
differential sur 
distance berwefc 
listed, 325 
point components 326 


25-330 

;m conversion. 329 
:ace area, 327 
t. points, 327 


proportional re: 

— 




lection and refraction, 


2^-330 

calculation, 330 
i lipping, 328 


refraction, 328 
relative depth, 1 
surface normal < 
surface normal ; 
vector length, 326-327 
vector normalization, 327 
geometric normal vector, global variable for, 293 
geometric primitives See primitive object types 
geometric transforms tion environment 
bounding boxes, 124-125 
coordinate sy steins, 

handedness of, 119-122 
local coordinate systems, 109-110 
named coordinate systems, 122-124 
naming coordinate systems, 123 
transforming an object's coordinate 
space into the current space, 123-124 
current transformation, 53, 109, 110-112 
cleaning, 11 6— 1 17 

marking as viewing transformation, 
140-141 
replacing, 117 

in- and out-facing surfaces, 118-119 
orientation, 119-1^2 


See also geometric transformations; graphics 
environment 
geometric transformations 
accumulating, 26-27 

eliminating confusion arising from, 
27-29 

data type for, 41 
defined, 21 

genera] linear transformations, 115-116 

general nonlinear transformations, 117-118 

interaction of, 23 

order of performing, 22, 140-141 

perspective transformations-, 113-115 

rotation, 21-22, 26-27, 112 

scaling, 113 

skew transformations, 113 
stacking, 27-29 
translation, 21 , 22, 1 12 
for dewing transformations 142 
Sec also geometric transformation environ- 
ment; transformation blocks 
geometry. Sec Constructive Solid Geometry 

VCSG; 

geometry matrix (control hull) 

for bicubic patches, 87, 88, 90, 92, 95 
for bicubic patch meshes, 95 
geometry vector (control hull), for bicubic 
splines, 90 

global coordinate system, mapping local coordi- 
nate systems to, 251 
global variables, 284, 291-296 
listed, 292, 296 

glowing surface shader, definition of, 368-370 
gouged surface displacement shader 
definition of, 378, 379 

See also dented surface displacement shad- 
er; embossed surface displacement 
shader; pitted surface displace- 
ment shader 

Gouraud shading, 214, 215 
granite surface shader, definition of, 354 
granularity, of viewing surfaces, 4 
graphics (computer) 

camera models used in, 7-8 
three-dimensional, basic model of, 2 
graphics environment (graphics state) 
aggregate objects and, 108 
attributes, 44, 46-47 
capabilities, 44-45 
defined, 23 

hierarchical nature of stack, 109 
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initializing, 18 

modification of by procedures, 44 
options, 44, 45-46, 47, 48-49 
shaders and, 213-216, 217, 260 
texture mapping and, 251 
types of information in, 44-47 
See also geometric transformation environ- 
ment 

graj/, dark, specifying the color, 22 

H 


halway vector, 226, 226 
har dedness of coordinate systems, 119-11 
default, 119 

forcing a change in, 122 


121-122 
rules governing, 120-121 
setting, 121 

header files, r :.h, 38, 40 
he^c tilting, 144 
height fields. 246 
hemispheres. See spheres 
Hermite splines, for bicubic patches, 91-92 
Hepnite spline segmentation 
for bicubic patch meshes, 98 
with wrapping, 103 
hidden surfaces 

eliminating for rendered images, 6, 54 
depth {z value) and, 173 
of na rural images, 3 
hidrarchical geometry. See geometrical transfor- 
mation environment 
hidrarchical modeling 
benefits of, 108 
example of, 108 
in graphics environment, 109 
and nesting of procedure blocks, 48, ICS 
in object instancing, 110, 133-134 
overview of, 107-108 
in scene description, 109 
in solids modeling, 110, 126 
terms defined, 109 

See also geometrical transformation environ- 
ment 

highlights, 226 

holdout mattes, specifying, 215-216 
homogeneous coordinates, 88 
hourglass hyperboloids, 64 


hue, saturation and value (HSV) color represen- 
tation, 289 
hyperboloids 

cones and cylinders as special case of, 63-64 
curved, 

generating, 64-65 

polygonal approximation of, 71, 72 
polyhedral approximation of, 50-82 
with texturing, 253-256 
declaring, 63 
defined, 60 

parameter space of, 246-247 
sweep angle of, 64 


I 

/ (global variable), 292, 296 
if-then-eise construct (shading language), 300 
illuminance construct, 302-305 
illuminate construct, 305-30S 
illumination 
defined, 209 

switching on/off, 21 7-21 S 
See also light sources; iighr source shaders 
Illumination and Color in Comvuter Generated 
Imagery (Hall), 237 
image aspect ratio, 157-159 
image definition mode, 47-48 
image plane, 139, 141. 146. lo7 
imager shaders, 181, 2S0 
images 

boundaries of, 151 
controlling, 20-23 
creating files for, 160, 161 
cropping, 139, 162-164, 165 
defined, 159 

defining, 45-46, 47-48. 139 

destination specification for, 154-155 

distorted, 158-159, 161-162 

examples of, 386 

false contours in, 1S4-1S5 

frames vs., 159-160, 165. 166 

internal representation, 5 

naming files for, 19, 155 

natural, 2-5 

options, 44, 45-46, 47 

output specification summary for, 164-166 
projecting three-dimensional scenes onto 
two-dimensional, 137, 139, 146 
as raster, 9, 172 

resolution of, 139, 156-157, 165, 166, 182-183 
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screen wmdowfs relationship to, 157-162, 
166 

size of, 146, 15/ 
storing, 154-154, 160, 16] 
tilting, 1 

imagine pipeline, 17(4, 175 
incident cone, 302 
incident vector, 226 
inflection edge, defined, 363 
initializing, graphics environment, IS 


efined, 31 , 33 
!, 283-264, 296-297 

$3-134 


ce construct and, 305 
r 5, 184 


instance paradigm., 
instance variables, 2$|7 
instancing 

objects, 31 , 1 1 0, ' 
shader procedures, 21 1-212 
integer data type 41 
integration, illuminanc 
intensities, rabo of, 1! 
interior volume shaders, 235, 27S 
internal represents tic n. 5 
interpolation 

basis of, 244-245 

for bicubic patch is and meshes. 245-246 
for bilinear patches and meshes 86-87, 
245^246 
linear, 86-S7 

motion blur and, h 87-188 
Phong interpolation, 73-75 
for polygons, 248 
for quadric surfaces, 246-247 
shading and, 212,215 
Sec also variables 

intersection operation ((Constructive Solid 
Geometry), 1^6, 128-130 

j 

jaggies, 10, 174 
jittering, 175 

K 

Knickknack, 367 


L (global variable), 292, |296 
label surface shader, definition of, 384 
latitude-longitude environment map, creating 
263 

leaves (hierarchical), defined, 109 


left-handed coordinate systems, 119-122 

left-handed rotation, 21, 112 

length 0 function, declaration of, 326-327 

lenses 

depth of held of, 5 

fisheye, field of view setting corresponding 
to, 150 

as optical system, 4 

telephoto, field of view setting correspond- 
ing to, 150 
level of detail 

calculating, 195-196 
current, 195, 196 
defined, 194, 195 

overview of, 1 94 
programs, 

dissolving a crude model into a refined 
one, 200 

geodesic dome, 198-199, 200 
range of detail, 
declaring, 197 
meaning of. 197-198 
smooth transition between alterna- 
tives, 199-200 
relative, specifying, 196 
using, 196-197 

light 

global variables for, 294 
and natural images, 2-5 
and rendered images, 

calculating light travel, 5-6 
exposure modeling, 1 79-1 80 
hid den -surface elimination, 6, 54, 173 
See also light sources; shading 
light bulb shaders, 366-370, 374-375 
light emission 

model of, 306-307 
natural images and, 2 
rendered images and, 210 
lighting functions, declaration of, 315-319 
light source handles, 41, 21 6 
light sources 

ambient, 218-219, 303-304, 315 

area, 224-225 

defined, 6 

distant, 20-21, 221 

point, 221, 224, 339 

positioning, 223-224 

preparing, 20-21 

rendering images without a light source, 18, 
232, 362-363 

surface appearance and orientation to, 73 
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switching on/off, 217-218 
When they can be declared, 49 
5*e also ambient reflection; diffuse reflec- 
tion; light source shaders; shadow 
mapping; specular reflection 
(mirror reflection) 
light sjource shaders, 216-225 

ainbient shader, 218-219, 337-338 
area shader, 224-225, 307-308 
declaring, 210, 215 
default, 21,23, 219 

d stant shader, 210, 219-221, 308, 338-339 
illuminate construct and, 305-308 
irstancing, 211, 212, 216-217 
model of light emission for, 306-307 
ppint shader, 210, 211, 221, 307, 339-340 
program for invoking the four basic sources, 
220 


pUrpose of, 210, 211, 216, 27S 
siylight shader, 308-309 
sijide projector light shader, 371-374 
spiar construct and, 305-306, 308-309 
spotlight shader, 210, 222-223, 340-341 
shadow-mapped, 268-270, 37S-57 G 
See also light sources 
linear interpolation, 86-87 
linear transformations. See geometric transfor- 
mations 

local doorcinate systems, 109-110 
establishing, 47, 111 
geometric hierarchy and. 110 
n apping to global coordinate system, 251 
returning to camera space, 117 
returning to world space, 117 
local variables (shading language), 2S4. 29 7 
log() rtmcdon, 312 

Luxo yr. in " Light Entertainment," 387 


M 

macros. See object descriptions 
main flock, defined, 48 
MakeAefl.c program, 266-267 
map access functions, 319-324 
arguments to, 320-321 
bump map access, 322-323 
definition of map, 319 
environment map access, 323-324 
overview' of, 319 
shadow map access, 324 
texture map access, 322 
types of map, 319-320 


mapping 

local coordinate systems to global coordi- 
nate system, 251 

an object's coordinate space into the current 
space, 123-124* 

parameter space to texture space, 250-251 
shader-space coordinates :o colors (shading 
language), 347-348 

texture-space coordinates to colors (shading 
language), 344-345 
world space to camera space, 141-142 
See also bump mapping; environment 

(reflection) mapping; shadow map- 
ping; surface mapping; texture 
mapping 
M apSunORi), 254-255 
marble surface shader, 354-356 
mathematical functions, 511-314 
derivative functions, 313 314 
integration, illuminance construct and, 305 
listed, 312 
overview of, 311 
splineO function, 311-313. 314 
See also noiseO function 
matrix, transformation, 115-116 
matrix data type, 41 
mattes, hold-out, specifying, 215-216 
matte surface shader 

definition of, 334-356 
invoking, 232 
purpose of, 22, 232 
rubber eraser version, 3S5 
See also diffuse reflection 
maxO function, 312 
meshes 

defined, 94 

See also bicubic patch meshes; bilinear 
patch meshes 

messages, printing from a shader, 332 
metallic wire mesh surface shader, definition 
of, 348—349 
metal surface shader 
definition of, 336 
with environment map, 379-381 
invoking, 232-233 
literature on, 237 
purpose of, 232 
min() function, 312 
mirror direction, defined, 230 
mirror reflection. See specular reflection 
mix() function 
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declaration of, 331 
functioning of, 341 
roodQ function, 312 
modeling 

rendering vs., 1H12, 13-14 
See also Constructive Solid Geometry (CSG); 
hierarchical modeling; procedural 
models 

modeling transformation, 142 
modes 

display mode, 15a 
of Render Man Interface, 47-46 
monochromatic color spaces, 43 
motion blocks, 186-191 
motion blur, 1 86-1 92 

commercial animapor examples, 192 
declaring motion, 1 86-1 91 
defined, 4-5, 45, 16c 
literature on, 1 91 
moving a scene, 187-186 
specifying motion blur, 186 


N (global variable), 292, 29c 
naming 

coordinate systems, 123 
display, 1 55 
na rural images, 2-5 
nesting 

blocks, 27, 46,49 

attribute blocks, 45. 49-50 
frame blocks, 51 
hierarchical mode! and, 108 
main block, 46 
transformation blocks 1 1 1 
world blocks, 45, 109 
illuminance statements. 303 
Ng (global variable), 292, 296 
nodes, defined, 109 
noise, adding. See dithering 
noiseO function 

declaration of, 314, 332 
shaders using, 

blue-marble surface, 354-356 
dented surface, 350-352 
eroded surface, 352-353 
granite surface, 354 
rubber surface, 385 
wood-grain surface, 350, 353 
nonlinear encoding of color data, 179-180 


nonlinear transformations, 1 1 7-1 1 8 
non-planar polygons, 69-70 
non-uniform rational B-splines (NURBs), 85, 
103-105 

trim curves for, 103, 249-250 
normal. See geometric normal vector; shading 
normal vector; surface normal vector 
normalizeO function, declaration of, 327 
null hider type, 54 
null mode, 47 
null token, 19, 39 

NURBs. See non-uniform rational B-splines 

0 

object descriptions, 31 
object handles, 31, 41, 133 
objects 

aggregate, 31-33, 107-108 
attributes of, 44, 46, 47 
closed, defined, 116 
defined, 107 

instancing (duplicating), 31, 110, 133-134 

onesided, defined, 119 

opaque, 116-119 

open, defined, 118 

size of, 195 

bounding box and, 124-125, 195-196 
increasing, 141 
solid, defined, 126 
specifying, 133-134 

cab-by-value nature of, 24-25 
commutative nature of, 27 
for moving objects, 190 
and procedures affecting object charae 
teristics, 22, 23 

using instance paradigm, 31-33 
using procedural paradigm, 19, 23-31, 33 
structured, 14 
translucent, 119 

See also primitive object types; procedural 
models; surfaces 
object space, 52, 53, 111, 123 

map an object's coordinate space into the 
current space, 123-124 
object space shaders, 344-350 

01 (global variable), 292, 296 
opacity 

global variable for, 292 
specifying, 213, 344-349 
See also alpha 
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opaque data types, 41 

opaque objects, 118-119 

open objects, defined, 118 

operators (shading language), 298 

optical systems, purpose of, 4 

op a on blocks, 50 

options 

attributes vs., 47 
default settings for, 44 
defined, 44, 45-46 
modon biur and, 191 
non-standard, 46 
order of specifying, 140 
setting, 46 
shaders as, 212 
stacking, 50, 51 

when they can be set, 47, 48-49, 140 
order 

of calling procedures, 22 
or performing transformations, 22, 140-141 
of vertex specification, 19 
orientation 

of camera, 140 

inside and outside of surfaces and, 119 
left- vs. right-handed coordinates, 119-122 
of parametric surfaces, 120, 258 
of polvgonallv approximated curved surfac- 
es, 73 

of polygonal surfaces, 258 
of quadric surfaces, 119, 120, 258 
representation of, 73 
shading and, 6, 73-74 
of smoothly curved surfaces, 73 
orthogonal (r) direction, 92 
orthographic projection, 8, 146, 150 
Os ; global variable), 292, 296 

P 

P ' global variable), 292, 296 
painter s algorithm, 54 
paraboloids 

declaring, 66 
defined, 60, 65 
parameter space of, 246-247 
paradigms, of object creation, 33 
parameter-interpolation technique, 188 
parameter lists, 39-40 

map access functions and, 320-321 
texture mapping and, 252 
variables used in, 242-244 


parameter space 

of bicubic and bilinear patches and meshes, 
245-246 
defined, 245 
global variables, 293 
mapping to texture space, 250-251 
of polygons, 248 
of quadric surfaces, 246-247 
shaders and surface maps and, 248 
trim curves and, 249-250 
parametric surfaces 
classes of, 85 
defined, 59, 86 
handedness rule for, 120 
interpolation for, 245-246 
non-uniform rational B-solines (NURBs), 

85, 104-105, 249-250 
overview of, 85 
programs, 

bicubic patch generation, 88, 59, 94 
general surface of revolution genera non 
using bicubic patch mesh, 100, 101 
with wrapping, 101-103 
surface normal vector for, 120, 258 
texture mapping for, 250-251 
uniform non-radonal patches, 85, 86-103 
See also bicubic patches; bicubic patch mesh- 
es; bilinear patches; bilinear patch 
meshes 

parent node, defined, 109 
patches. See bicubic patches; bicubic patch 
meshes; bilinear patches; bilinear 
patch meshes 
pencil shaders, 381-385 
Perlin, Ken, 332, 350 
perspective projection 

declaring a. 21, 139, 149-154 
defined, 8, 146 

perspective transformations, 113-115 
phongO function, declaration of, 316-317 
Phong interpolation, 73-75 
Phong reflection, 316-318, 332 
pictures. See images 

pin-color surface shader, definition of, 375-378 

pinhole viewer, 4, 8, 155-186 

pipelines 

imaging pipeline, 174, 175 
shading pipeline, 209-21 0 
pitted surface displacement shader 
definition of, 375 
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See also dented surface 


displacement 


shader; gouges surface displace* 
men: shader 
pixel aspect ratio 
default, 156, 165 

specifying, 139, 156-35}, 165, 166 
pixels 

and aliasing, 10, ITS, 17jr-175 
alpha storage in, 156, 17 3-174 


73,182-184 


179 


tion stored at 


arriving at rendered, 1 6 5—165 
color representation in, 5-9, 42-43, 156, 173 
defined, 8-9 

depth iz value) storage ijn, 156, 173 
dithering, 183, 184-185 
and exposure, 179-160 
fidelity of, 178-179 
filtering, 9-10, 174-179 
imaging, 181 

imaging pipeline and, 124, 175 
model of rendering. 172 
options, 45-46 
purpose of, 137 
quantization of color 

relationship between scejie data and image 
pixels, 160 

as samples, 9, 43, 173 
as screen dots, 9 
specif} ing type of iriormbt 
each pixel, !5r 
supersampling, 174-378 
See also resolution 

P&ceCameraQ program, 142-lj45, 154 
placement, of camera, 140, 142(-145, 154 
planar polygons, 69-70 
plastic surface shader 
definition of, 336-337 
invoking, 233 
purpose of, 233 
with texture map, 374 
wire mesh version, 348-349 
point data type, 281, 284, 288-240 
arithmetic on, 298 
comparison of, 299 
cross product of, 299-300 
dot product of, 299 
pointer data types, 41, 244 
point functions 

components of points, 326 
distance between points, 32j7 
point light sources, 221, 224, 339 
point light source shader, 210, 2^1, 221, 307 
definition of, 339-340 


point sampling, 9, 43, 173, 174-179 
points-polygons form, 79 
PolyBoidO program 
basic version, 71, 72 
Phong interpolation version, 74-76 
polyhedral version, 80-82 
polygons, 69-63 

bilinear patches as alternatives to, 86-90 
curved surface generation using, 69, 71, 72, 
74-76 

deteimining qualitv of approximation, 
171-172 

drawbacks, 75-78 
fiat shading problem, 71-78 
declaring, 

concave with holes, 78-79 
convex no holes, 70 
defined, 59, 69 

handedness rule for, 120-121 
interpolation for, 248 
parameter space of, 248 
subdividing surfaces of, 71-73 
surface norma] vector for, 258 
texture mapping for, 251 
ripes of, 69-70 
vertex specification for, 19 
Sec also polyhedra 
polvhedra, 79-83 

curved surface generation and, 80-82 
declaring, 

concave with holes, 78, 82-83 
convex, no holes, 78, 79-80 
defined, 69 

points-polygons form, 79 
polynomial curved surfaces. See parametric sur- 
faces 

PolySurfORQ program, 74-76 
position, global variables for, 293 
positive rotation, 21 -22 
pow() function, 312 
Pratt, M.J., 65 

predefined variables (tokens), 42, 243-244 
primitive object types 
attributes of, 46 

common coordinate system for, 124 

defined, 46, 59 

nature of, 14, 59 

in object descriptions, 31 

object space and, 53 

turning inside out, 122 

when they can be declared, 48, 49 




-60 


Index 


1 



See also parametric surfaces; polygons; 
quadric surfaces 

primitive solid object, defined, 126 
primitive surfaces. See parametric surfaces; 

polygons; quadric surfaces 
prin :f() function, declaration of, 332 
procedural models, 201-208 
declaring, 201-203 
defined, 194, 201 
level of detail and, 193-200 
overview of, 201 

proeram for fractal triangle generation, 
203-206 

procedural paradigm, defined, 33 
proc edural texrunng, 343-360 
aliasing reduction, 348-349 
biue-marbie surface, 354-356 
checkerboard surface, 345-347 
defined. 343 
dented surface, 350-352 
eroded surface. 352-353 
granire surface. 354 
mapping shader-space coordinates to 
colors, 347-34S 

mapping rextur e-space coordinates to 
colors. 344-345 

metallic wire mesh surface, 348-349 
window highlight, 356-359 
window light, 359-360, 361-362 
wood-grain surface, 350, 353 
procedures 
calling, 

calls grouped into blocks, 47 
order of. 22 
data types, 40-44 
error handling, 3S-39 
graphics state modification by, 44-47 
implicit side effects of, preventing, 27-29 
overview of, 37-38 
parameter lists, 39—40, 242-244 
refinement procedures, 201-203 
"Ri" prefix explained, 37 
time-varying, listed, 191 
vectorized versions of, 40 
See also functions; programs; shaders; specific 
procedures by name 
prqgramming languages 

compatible with RenderMan, 17-18 
See also C 


prqzrams 


camera specification program, 142-145, 148- 
154 


data handles, scope of, 51 
data types, 40-44 

dissolving a crude model into a refined one, 
200 

environment (reflection) map programs, 
263-267 

fractal triangle generator program, 203-208 
geodesic dome program, 198-199, 200 
light source invocation program, 220 
a minimal program, 17-20 
procedures and, 37-38 
required elements of, 44 
shadow map program, 269-270 
square display program, 17-23 
structure of, 4*7-51 
for surface of revolution generation, 
bicubic patches, 88, 89, 94 
with texturing, 252-253 
quadric surfaces, 61 

with texturmg, 253-256 
solid surface of revolution, 127 128-129, 
131 

toroidal wave, 67-68 
using bicubic patch mesh, 100, 101 
with wrapping, 101-103 
using hyperboloids, 64-o5 
using polygons, 71 72, 74-76 
using polynecra, 80-82 
template for, 54-55 
unit cube animation program, 33-34 
unit cube display program, 24-32 
viewing program, 

boilerplate, 138-141 
improved boilerplate, 167-169 
See also functions; procedures; shaders 
projection 

defined, 4 

depth of field and, 5 
model of, 146-149 
orthographic projection, 8, 146, 150 
perspective projection, 

declaring, 21 , 139, 149-154 
defined, 8, 146 
skew projection, 53 
specifying, 139, 149-150 
proportional reflection and refraction function, 
declaration of, 328-329 


Q 

quadric surfaces, 59-66 
closing partial, 128-130 
cones, 60, 62-64 
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cylinders, 60, 63, 64 

solid partial, 12|3-130 
defined, 59, 60 
defining, 60 
disks, 62-63 
handedness rule tor 120 
hyperboloids, 60, 63}-64 

curved, 64-65, 7 L, 72, 80-82, 253-236 
illustrated, 60 
interpolation for, 24f-247 
paraboloids, 60, 65-t 6 
parameter space of, 246-247 
programs, 

general surface of revolution generation 
using hyperboloids, 64-65 
six different auairic surfaces generated, 
61 

toroidal wave generation, 67-68 
spheres, 60, 62 

solid partial, 128-130 
surface normal vector for, 119, 120, 258- 
sweep angle, 60 
texture mapping ror, 250-251 
ion, 60, 66—68 
types of, 60 

quantization, 10, 175, 182-184 

transforming color befpre, 181 

R 

radians') function, 312 
radiosit}*, illuminance const 
raster 

defined, 9, 172 
target raster, 166 
See also pixels; raster spice 
raster space, 53, 122 

area of a surface eiemenjt in, 3: 
level of detail in, 1 95 
ray tracing 

drawbacks of, 261 

illuminance construct anti, 304, 318-319 
ray tracing function, declaration of, 318-319 
recursion (shading language)! 288 
red-green-blue color representation, 42-43, 156, 
226-227 

Reeves, William T. ; 271 
refinement procedures, 201-203 
reflection 

color of, 226-227 
defined, 209-210 
global variables for, 294 


*uct and, 304-305 


in natural images, 2-3 
pr oportional reflection and refraction 
function, 328-329 
See ai$c ambient reflection; diffuse 

reflection; specular reflection 
(mirror reflection) 

reflection mapping. See environment (reflection) 
mapping 

refractO function, declaration of, 328 
refraction, 3 

function for, 328 

proportional refraction and reflection 
function, 326-329 
relative index of, defined, 328 
relative depth function, declaration of, 329-33C 
Tenderers, capabilities of, 44-45 
rendering 

defined. 137 

key parts of process, 1 , 59 
modeling vs., 11-12, 13-14 
when it can begin, 49 
RenderMar. Interface 
benefits of, 387 

features not included in, 15-16 
features of, 14-15, 24-25 
initializing, 18 
modes of, 47-48 

programming ianguases compatible with 
17-18 

purpose of, 5, 12-14 
Tenderer capabilities and, 44-45 
rendering vs. modeling considerations, 11-12 
shading complexities and, 7, 12-13 
as a standard, 15, 387-388 
Render.Man shading language. See shading 
language 
resolution 

default, 1 66 
defined.. 9 

low vs. high, 182-183 
as option, 45-46 
raster space and, 53 
specifying, 139, 156-157, 165, 166 
texture mapping and, 257 
restoring /saving. See stacking 
retained models, 133-134 
return statement (shading language), 301 
RGB color representation, 42-43, 156, 226-227 
RiAreaLightSourceO, declaration of, 225 
RiAtmosphereQ, declaration of, 234 
RiAttributeO, declaration of, 46 
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RiAttributeBeginO 
declaration of, 50 
graphics stare and, 112 
nesting calls to, 49, 50 
purpose of, 29 , 47 , 50, 108 
RiAttributeEndO 
declaration of, 50 
graphics state and, 112 
purpose, 29, 47, 50, 108 
RiBasisO, declaration of, 93 
RiBeginO 

declaration of, 48 

mode of RenrierMan Interface and, 47—S 
nested calls not permitted, 4S 
purpose of, 5 

RiBoundf , declaration of, 125 
RtBoxFilterO, 176-178 
RiCatmullRomFiiterO, 176-178 
RiClippingO, declaration of, 145 
RiColorO 

declaration of, 213 

graphics stare modification by, 44, 213 
using, 22-23, 46 

RiCoior5ampies;\ declaration of, 43 
RlConcatTransformO, declaration of, 116 
RiConeO, declaration of, 62 
RiCoordinateSvstemO, declaration of, 123 
RjCropVVindow 1 ) 

declaration of, 162 
purpose of, 139, 162 
using, 163 

RiCviinderO, declaration of, 63 

R<i Declared, declaration or, 242-243 

RiDeformationO 

declaration of, 117 
transformation shaders and, 279 
RiDetaiiO, declaration of, 195-196 
RiDetailRange';, declaration- of, 197 
RiDiskO, declaration of, 62-63 
RiDisplacementQ, declaration of, 260 
RiDisplav() 

animation and, 33 

declaration of, 155 

and filling display with scene, 160 

purpose of, 139, 155, 157 

RiFormatO and, 165-166 

shadow mapping and, 268 

and windowing onto a display, 161 


RiEndO 

declaration of, 48 
purpose of, 18 

RiErrorAbortO, declaration of, 38 
RiErrorHandlerO, declaration of, 38 
RiErrorlgnoreQ, declaration of, 38 
RiErrorPrintQ 

declaration of, 38 
using, 39 
RiExposureQ 

declaration of, 180 
false contours and, 184 
RiExteriorO, declaration oh 235-236 
RiFormatO 

declaration or', 156-157 
purpose of, 139, 157 
RiDisplayO and, 165-16o 
and windowing onto a display, Icl 
RiFrameAspectRatioO 
declaration of, 159 
purpose of, 153, 159., loO 
RiFrameBeginO 

declaration of, 51 
object instancing and. 133 
purpose of, 33, 50, 51 
RiFrameEndO 

declaration of, 51 
purpose of, 33, 50 51 
RiCaussianFilterO, 176-17S 
RiCeneraiPolygonO, declaration of, 7S-79 
RiGeometricApproximationO, declaration of, 
172 

right-handed coordinate systems. 119-122 
right-handed rotation, 112 
rlh, 38, 40 

RiHiderC 1 . delcaration of, 54 
RildentitvQ 

declaration of, 117 
using, 143 

RillluminateO, declaration of, 217-218 
Rilmager(), declaration of, 181 
RilnteriorO, declaration of, 235 
RiLightSourceO 

declaration of, 216, 219-222 
purpose of, 212 
using, 20-21 

RiMakeBumpO, declaration of, 259 
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RiMakeCubeFaceEnvironmentO, declaration of, 
265-264 

RiMakeLatLongEnvironmentO, declaration of, 
263 

RiMakeShadowO, declaration of, 269 
RiMakeTextureO, declaration of, 256-257 
RiMatteO, declaration of, 216 
RiMotionBeginO 

declaration of, 189 
purpose of, 188-189 
usage examples, 189-190 
RLNULL token, 19, 39 
RiNuPatchQ, declaration of, 104 
RiObjectBeginO 

declaration of, 135-134 
purpose of, 31, 110, 135-134 
RiObjectEndO 

declaration of, 133-154 
purpose of, 31, 110, 133-134 
RiObjectlnstanceO 
declaration of, 134 
purpose of, 31, 134 
RiOpacitvQ, declaration of, 213 
RiOptionQ, declaration of, 46 
RiOrientationO, declaration of, 121 
RiParaboloidO, declaration of, 6c 
RiPatchQ, declaration of 87-88 
RiPatchMeshQ 

declaration of, 98 
purpose of, 94 

RiPerspectrveO, declaration of, 114 
ri.vic, 19 

RiPixelFiiterO, declaration of, 176-178 
RiPixelSamplesO 

declaration of, 176 
purpose of, 176, 178 

Ri Pixel VarianceO, declaration of, 176-179 
RiPointsGeneralPolygonsO 
declaration of, 82-83 
input topology required by. 70 
RiPointsPolygonsO 

for cube generation, 80 
declaration of, 79-80 
input topology required by, 70 
RiPolygonO 

declaration of, 70 

input topology 7 required by, 70 

object space and, 52 


order of vertex specification for, 19 
square creation and, 19 
unit cube creation and, 24 
using, 19 

Ri Procedural!'), declaration of, 201-203 
RiProjectionO 

declaration of, 149-150 
field of view parameter, 150, 153 
purpose of, 21, 53, 139, 150 
RiScreenVVindowO and, 153 
transformation shaders and, 279 
RiQuantizeO 

declaration of, 183-184 
false contours and, 185 
RiRelativeDetailQ, declaration of, 196 
RiReverseOrientationQ, declaration of, 122 
RiRotateO 

declaration of, 112 
graphics state modification by, 44 
purpose of, 21, 112, 140 
using, 21-22, 26-27 
RiScaleQ, declaration of, 115 
RiScreenWindowO 

declaration of, 150-152 
purpose of, 139, 150 
RiProjectionO and, 153 
RiShadingRate \ declaration of, 214 
RiShutterO, declaration of, 190 
RiSidesO, declaration of, 119 
RrSincFilterQ, 176-178 
RiSkewQ, declaration of, 113 
RiSolidBeginO 

declaration of, 126-127 
difference operation, 130 
intersection operation, 128 
union operation, 130 
RiSoiidEndO, declaration of, 126-127 
RiSphereO, declaration of, 62 
RiSurfaceO 

declaration of, 231-233 
using, 18, 19, 22 

RiTextureCoordinatesO, declaration of, 251 
RiTorusO, declaration of, 66 
RiTransformO 

declaration of, 117 
using, 145 
RiTransformBeginO 
declaration of, 111 
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purpose of, 27, 47, 108, 111 
RiTrarisformEndO 

declaration of, 111 
purpose of, 27, 47, 108, 111 
RiTraijistormPointsO, declaration of, 123-124 
RiTraijislateO 

declaration of, 112 
purpose of, 21, 112, 140 
using, 21, 143-144 
RilriangleFilterQ, 176-178 
RiTrimCurveQ, declaration of, 249-250 
RiWoridBeginO 

durrenr transformation and, 53, 116 
declaration of, 48—49 
jested calls not permitted, 48 
c|bjec: instancing and, 133, 134 
purpose of, 18, 4S— 49 
yorld space and, 123 
RiWcjrldEndO 

declaration of, 48—49 
object instanang ana, 133, 134 
purpose of, IS, 48—49 
roll (camera), 144 
root poae, defined, 109 
rotation, 21-22. 144 

Cumulative effects of, 26-27 
defined, 21, 112 
handedness of, 21-22, 112 
positive, 21-22 
(specifying, 112 
translation and, 22 
roughness, 7, 231 
roundO function. 312 

routines. See functions; procedures; programs: 
shaders 

RtBoolean data tvpe, defined, 41 
RtCbior data type 
defined, 42—43 
using, 22 

Rt Float data type, defined, 41 
RtFloatFunc data type, defined, 42 
RtFunc data type, defined, 42 
Rtlnt data type, defined, 41 
RtLightHandle data type, defined, 41 
RtObjectHandle data type 
defined, 41 
using, 31 

RtPoint data type, using, 19 
RtPpinter data type 


defined, 4*1 
using, 19 

RtToken data type 

character strings vs., 42 
defined, 42 
using, 19 

RtVoid data type, defined, 41 
rubber surface shader, definition of, 3S5 


s (global variable), 292, 296 
sagging surface displacement shader, definition 
of, 370 

Salesin, David H., 271 
sampling, 174-179 

defined, 9, 173, 174 
number of samples, 43 
rate of, 1 78-179 

shading rate vs., 214 
temporal, for morion blur, 1S6-191 
saving/restoring. See stacking 
scalar data types, 41 
scaling, 113 
scattering 

defined, 3 
roughness and, 7 
scene definition mode, 48-49 
scene description 
defined, 59 

as root of obiect hierarchy, 109 
scene description methodology, defined, 12 
scenes 

changing the viewpoint of, 21-22 
creating, 59 
moving, 187-1SS 

projecting onto two-dimensional image 
planes, 137 

relationship berween scene data and image 
pixels, 160 

viewpoint rendered from, 141 
scope, of data handles, 51 
screen space, 53, 122-123 

projection into, graphic representation of, 
168 

screen surface shader, definition of, 348-349 
screen window 

default, 140, 152, 158, 167 
defined, 137, 139, 141, 146 
field of view and, 146-148, 152-153 
frame's relationship to, 160 
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r pefinition of, 384 
iaration of, 330-331 


image's relationship to, 15-162, 165, 166 
specifying, 150-1^4, 158, 166 
uncentered, 152 
sdixon surface shader, 
setcompO function, riei: 
setxcompO function, declaration of, 326 
setycompO function, declaration of, 326 
setzcompO function, declaration of, 326 
shaders 

common coordinate svsterr. for primitives 
and, 124 1 

and coordinate space in which shaders 
operate, 34S 

as dataflow module^, 276-277 
defining, 287-2SS i 
example shader, 2821-285 
graphics environment variables used by, 213 
imager shaders, 16l,]280 
instancing of, 211-212 
message printing in, jS32 
purpose of, 211, 273-274 
transformation (deformation i shaders, 
117-118, 2784279 
types of, 2/ /-2S0 

Sec also displacement fhariers; light source 
shaders; shading; shading lan- 
guage; surra c$ mapping; surface 
shaders; volume (atmosphere) 
shaders 


shading 

attributes for, 




, 132-133 


composite solid objects , 
constant, 215 
as data flow, 276-277 
density of, 21 4-2 1 5 j 

flat shading, 71-78 
generating, 51 
Gouraud shading, 214, i 
interpolation of, 21 5 
literature on, 237 
of natural images, 3 
orientation and, 73-74 
overview of, 6-7, 12-13, £09-2? 1 
rate of, 214-215 
shape vs*, 239-240, 274, 1 
smooth, 215 
suppressing, 21 5-21 6 
visual interest and, 12 

See also shaders; shading language; surface 
mapping 

shading functions, declaration of, 315-319 

shading language 


arithmetic on special data types, 298 
basis of, 285 

comparison of special data types, 299 
control constructs, 285, 300-301 
coordinate systems, 289-291 
cross product, 299-300, 359 
data prpes, 281 , 284, 2S8-2S9 
defining shaders and functions, 287-2S8 
do: product, 299, 359 
example shader, 282-285 
expressions, 298 

with vector times, 284-285 
features of, 280-282 
global variables, 284, 291-296 
listed, 292, 296 

illuminance construct, 302-305 
illuminate construct, 305-308 
instance variables, initialization of, 212, 
283-284, 29c-297 
local variables, 284, 297 
nature of shader programs, 283 
operators, 298 
overview of, 273-276 
purpose of, 22-13 
recursion not permitted in, 288 
resemblance to C, 283-284 287-288, 298-302 
return value, 285, 288 
and shaders as dataflow' modules, 2“6-2~7 
and shader types, 277-280 
solar construct, 305-306, 308-309 
special operators and functions, 284 
statements, 285, 300-301 
storage classes, 297 
svntax, 297-301 

See also functions; procedural texturing; 
shaders 

shading model, 15 

shading normal vector, global variable for, 293 
shading pipeline, 209-210 
shadowO function, declaration of, 324 
shadow' mapping, 268-270 

creating a shadow' map, 268-270 
literature on, 271 
map access function, 324 
purpose of, 257, 268, 320, 324 
for spotlight shader, 268-270, 378-379, 380 
shadowspot shader, definition of, 378-379, 380 
shape 

shading vs., 239-240, 274, 275 
visual interest and, 12 
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shiny surfaces. See environment (reflection) 
mapping; specular reflection (mirror 
reflection) 

slfiiny surface shader, definition of, 379-381 

ShowQuadsQ program, 61 

$foow_$t surface shader, definition of, 344-345 

snow^xyz surface shader, definition of, 347-348 

shutter (virtual), opening/ closing, 190 

siblings (hierarchical), defined, 109 

sides of surfaces, specifying visible, 119 

sjgnO function, 312 

s n() function, 312 

sfnc filter function, 176-178 

spe of image, 146, 157 

S-ze of model, and model's representation, 194 
size of objects, 195 

bounding box and, 124-125, 195-196 
increasing, 141 
skew projection, 53 
skew transformations, 113 
ky light shader, 308-309 
iiae projector light shader, definition of, 
371-374 

^meaning. See motion biur 
^mooth shading, 215 
^moothstepO function, 312, 348-349 
^olar construct, 305-306, 308-309 
SoiidCvlinderQ program, 129 
polidHemispher eO program, 128-129 
foiid objects. See Constructive Solid Geometrv 
(CSG) 

SoiidSphere 0 program, 129 
oiidSuriORQ program, 127 
olidV^edgei) program, 128 
r Dectral Color capability, RenderMan support 
of, 289 

;pecuiar() function, declaration of, 317 
specular reflection (mirror reflection) 
appearance of, 229 
calculating, 317-318 
defined, 3, 226, 230-231 
importance of, 231 
literature on, 237 
model of, 237, 317 
specifying, 228 

See also environment (reflection) mapping 
specular surface shader, definition of, 379-381 
spheres 

declaring, 62 


defined, 60 

non-uniform rational B-spline representa- 
tion of, 62 

parameter space of, 246-247 
program for creating and using a reflection 
map on, 267 
solid partial, 128-130 
spiineO function 

declaration of, 311-313 
functioning of, 314 
splines 

for bicubic patches, 90-92 
for bicubic patch meshes, 95-98 
non-uniform rational B-spiine surfaces, 
103-105 

spotlight shader 

default location of spotlight, 269 
definition of, 340-341 
invoking, 222-223 
purpose of, 222-223 
shadow-mapped. 268-270, 37S-5G? 
sqrtQ function, 312 
squares 

declaring, 19 

programs to display, 17-23 
unit square, 123 
stacking 

attributes, 29, 4!" 50 
geometric transformations, 27-29 
options, 50, 51 

starting, RenderMan Interface, 18 
statements (shading language), 285, 300-301 
stepO function, 312 
step values, 93 

storing images, 154-156, 160, 161 
streaking. See motion blur 
string data type, 288 
string identifiers, 42 
strobing effect. See motion blur 
structured objects, 14 
subdividing polygonal surfaces, 71-73 
subroutines. See functions; procedures; programs; 
shaders 

subtracting, Constructive Solid Geometry solids, 
130-132 

subwindows, 162-164 
supersampling, 174-178 
surface mapping, 241-250 

basis of interpolation, 244-245 
overview of, 239—241 
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patch and rAesh parameter space, 245-248 
polygon parameter space, 248 
quadric suriace parameter space, 246-247 
surface shac ers and, 242, 248 
variables, 

extending the set of, 242-244 
predefined, listed, 243 
varying vs. uniform, 241-242 
See also texture mapping 
surface normal vector 

calculation function, 330 
defined, 73 

fiat shading problem and, 73-77 
flipping funcion. 328 
orientation and, 119 
for parametri : surfaces, 120, 258 
for polygons, 258 
for quadric surfaces. 119. 120, 258 
shading and, 226 
surfaces 

attributes of, 4{±, 46, 4 
coherence of, 
controlling ap 
declaring. 55 
default appearjance of, 23 
defined, 2 
inside and outride of, 119 
orientation of. 7 3 

sides of. specif] ring visible 1 1-5-119 
variations m \* sua; interest and 12 
Sec a isc parametric surfaces polygons; 

quadric surfaces; shaders; shading 
surface shaders. 225j-235 

ambient reflection, 228, 229, 230 
blue-marbie shader, 354-356 
bowling pin shaders, 375-378 
checkerboard shader, 345-547 
clouds shader, 282-285 
color of refiecti opts, 226-227 
constant shader] 232, 334, 362-363 
diffuse refiecti or., 228, 229, 230, 231 
elements of surface shading, 226 
eroded surface shader, 352-353 
filament shader, 367-368 
functions that aid in writing, 315-319 
glow shader, 368-370 
granite shader, 3; >4 
illuminance construct and, 302-305 
instancing, 211, 2 12 
invoking, 231-233 

mapping shader-ipace coordinates to 
colors, 34F-348 


mapping texture-space coordinates to 
colors, 344-345 

matte shader, 22, 232, 334-336 
metallic wire mesh shader, 345-349 
metal shader, 232-235, 237, 336 
with environment map, 379-381 
orientation-sensitive shading without a 
light source, 362-363 
parameter space and, 248 
pencil eraser shader, 385 
pencil-labeling shader, 384 
plastic shader, 235, 33f^337, 348-349 
with texture map, 374 
purpose of, 210, 225, 279-280 
rubber shader, 385 

specular reflection (mirror reflection- 226, 
226, 229, 230-231, 237 
surface mapping and. 242, 244 
types of reflection, 227-229 
window highlight shader, 356-359 
window light shader, 359-360, 561-362 
wood-grain shader, 350, 351 
surfaces of revolution 
approximating, 193 

determining quality of approximation, 
171-172 
types of, 60-61 

See alsc parametric surfaces; programs for 
surface of revolution generation; 
quadric surfaces 
Sj~~DR{ program 

using bicubic patch mesh, 100, 101 
with wrapping, 101-103 
using hyperboloids, 64-65 
with texturing, 255-256 
sweep angle. 60 

of hyperboloids. 64 
synthetic camera. See camera (virtual) 
synthetic rendering. See rendering 

T 

; (global variable), 292, 296 
tan( function, 312 
target raster, 166 

ielephoto lens, field of view setting correspond- 
ing to, 150 

template, for standard programs, 54-55 
temporal aliasing. See motion blur 
tension, of curves, 92 

terrain data, compact representation for, 246 
TextSurfORQ program, 255-256 


•68 


Index 


texture 

defined, 6 

;sual interest and, 12 
texturfe coordinates, defined, 240 
texturK) function, 320-322 
declaration of, 322 
texture mapping, 250-271 

creating a texture map, 256-257 
example of, 240-241 
literature on, 271 
map access function, 319-324 
overview of, 250 
parameter list and, 252 
parameter space in, 250 
parameter- to texture-space mapping, 250- 
252 

plastic shader using a texture map, 374 
programs, 

bilinear patch, 252-253 
quadric surface, 253-256 
pose of, 13, 240, 250, 258, 319 
resolution and, 257 

slide projector light shader with, 371-374 
also bump mapping; environment 
(reflection) mapping; procedural 
texturing; shadow' mapping; surface 
mapping 
rexruije space 

global variables, 293-294 
mapping parameter space to, 250-251 
chapping to coior (shading language), 344- 
345 

npt uniform in world space, 346-347 
texturing, procedural. See procedural texrurmg 
threaded surface displacement shader, defini- 
tion of, 366-367 

three-pimensional computer graphics 
basic model of, 2 
coordinate systems, 51-53 
three-dimensional scene, transforming to a two- 
dimensional imase, 137, 139, 146 
162-163 
Wavne, 104 


tumg, 

iiller 

tilting 


head tilting, 144 
images, 152 

time-tariable RenderMan procedures, listed, 
191 

time-yarying-parameter technique, 18 8 

Tin 7 >v, 356-360 

tokens 


defined, 42 
in parameter lists, 39 
predefined, 42, 243-244 
RLNULL, 19,39 
See also variables 
token-value pairs 

examples of, 19, 39 
in parameter lists, 242-243 
tori 

declaring, 66 
defined, 60, 66 
parameter space of, 246-247 
toroidal w*ave generation program, 6~-68 
TorusWaveO program, 67-68 
traceO function, declaration of, 318-319 
transformO function, declaration of, 329 
transformation blocks 

common coordinate system of objects defined 
within, 108 
defined, 47 
nesting. 111 

transformations. See current transformation; 
geometric transformations: viewing 
transformation 

transformation shaders, 117-1 IS, 278-27^ 
translation 

defined, 21 

to make viewpoint coincide with coordi- 
nate origin, 143-144 
rotation and, 22 
specifying, 112 
translucent objects, 119 
transmission 

in na rural images, 2-3 
in rendered images, 299-210 
transparency giobai variable for, 292 
triangle filter function, 176-178 
triangles, procedural fractal generator for, 

203-208 

trichromatic color spaces, 42—43 
tricks, 360-370 

bevelled surface displacement shader, 

363-366 

drooping surface displacement shader, 370 
glowing surface shader, 368-370 
orientation-sensitive shading wnthout a 
light source, 362-363 
threaded surface displacement shader, 
366-367 

trim curves 

declaring, 249-250 
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defined, 103, 249 

two-dimensional coordinate systems, 53 
rwo-dimensionai imag >, transforming three- 
dimensional scene to a, 137, 139, 146 
tw o-dim ensiona! nature, of viewing surfaces, 4 


u (global variable), 292, 296 
it (direction), 92 
uniform non-rahona] patches. See bicubic patch- 
es; bicubic patch meshes; bilmear 
patches; hiiine; ir patch meshes 
242. 244 
e, 29/ , 3 !j> 

ucrive Solid Geometry), 


uniform variables, 212, 
in shading languadi 
union operation (Const! 

‘126,130 

UnitCube 0 program. 23j-^y, 
uni: cubes 

animating, SS-54 
defining, 24-29, 80, 81 
defining color, 29-22 
nine tv-decree perspective transform on, 
114-113 

uni: square. 123 

V 

l l global variable* 292, 296 
r i direction), 92 
variables 

extendmg the set on 242-244 
predefined. 243-244 
ir. shading ianruage, 
global, 2B4. 291-296 
instance variables, 212, 283-284, 
296-297 
local, 284, 257 
uniform, 297, 31 : 5 
varying, 297, 31; 
uniform, 212, 242, 244 
varying, 212,242, 24 - 1 
See also tokens 
vector data types, 41 
vectorized versions of procedures, 40 
vectors 

geometric normal vettor, global variable 
for, 293 

halfway vector, 226 
incident vector, 226 
length function, 326- 527 
normalization function, 327 


shading normal vector, global variable for, 
293 

See also surface normal vector 
vertices 

defined, 19, 69 

of polygonal curved surfaces, flat shading 
problem and, 71-78 
spedhhng, 
order of, 19 

for polygons, 19, 70, 78-79 
for poivhedra, 79-80, 82-83 

view 

default, 19-20, 139 
denning parameters, 21-22 

boilerplate program for, 138-141 
improved boilerplate program for, 

‘ 167-169 
options, 45 

viewpoint scenes are rendered from, 141 
See also camera (virtual) 
viewer 

changing the, 21-22 
defined, 2, 4 
light and, 2. 4 

\hewing devices, natural images and, 4 
\iewing direction, defined, 141 
viewing location, defined, 141 
viewing pyramid, 114 
viewing surfaces 

natural images and, 4, 9 
rendered images and, 8-9 
viewing transformation, 141-142 
clearing, 143 

marking current transformation as the, 
140-141 

simple program for, 142-145 
See also current transformation 
virtual camera. See camera (virtual) 
visible sides of surfaces, specifying, 119 
visual artifacts, natural images and, 4-5 
visual interest 

level of detail and, 194 
sources of, 12, 274 
volume, defined, 234-235 
volume (atmosphere) shaders, 233-237 
default, 235 

depth-cue shader, 236, 237, 341-342 
fog shader, 236-237, 342-343 
instancing, 212 
interior /exterior, 235, 278 
purpose of, 210, 233235, 236, 278 
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specifying, 235 

See also shading language 


W 


while construct (shading language), 301 
wldte, specifying the color, 22, 227 
window highlight shader, definition of, 

356-359 

windowing onto a display, 161 
window light shader, definition of, 359-360, 
361-362 

wi ndow of evaluation. See evaluation window 
(bicubic patch mesh) 

wi mesh surface shader, definition of, 348-349 
wcod-gram surface shader, definition of, 350, 
351 

wcrid, describing the, IS, 48-49 
w'crid blocks, 48-49 
nesting, 48, 109 
retained models and, 133, 134 
as root of object hierarchy, 109 
within frame blocks, 51, 133 
woHd space.. 52, 53, 116, 123 

returning local coordinate system to, 117 
texrure space not uniform in, 346-347 
transforming to camera space, 141-142, 
144-445 

wofn surface disnia cement shader, definition of, 
350-352* 

wT^pping, bicubic patch meshes, 98, 100-103 


xcojmpQ function, declaration of, 326 

Y 

vconpO function, declaration of, 326 

z 

zcojnpO function, declaration of, 326 


